So the idea is to get one step closer to iOS’s universality of APIs?
But forcing the changes down devs’ throats isn’t.
Google has emitted a new beta of Android P, but it's not obvious how excited to get about it. We’re conflicted because Google has described the new release as "an early release candidate build" and says the full release is due "later this [northern] summer". Which suggests this release could probably be skipped given the …
You mean the OS where you're not allowed to render a website in any other way than an Apple control.
Google Chrome on iPad / iPhone is just a Safari control in a different coloured box.
I'm not at all sure that "universality" of APIs is an no-questions-asked good thing in and of itself. There has to be something else too in order to ensure you can program against them freely.
Also note, it's impossible to do certain things on iOS programmatically at all, by design. Sure, that saves you a few small security headaches but the amount they MISS tells you that that isn't the end of the story either. And causes huge user interface problems.
Don't even get me started on the junk that is screen-modal pop-up login dialogs that don't tell the user their origin, and go over the top of anything you happened to be doing.
"So, developers are going to miss out their (northern) summer holidays"
Not every country has a bunch of holidays during that time. Australia, the Land of the Long Weekend, has a holiday period roughly from shortly before Christmas eve to shortly after New Years, which is summer for us, and obviously not (northern) summer. This is not an official holiday period, other than the usual Christmas and New Years holidays, the rest is simply "Meh, we are closed for a couple of weeks" for the majority of companies / government departments. Or the silly season as it is known. I suspect a lot of other countries also close down most things during that period. We don't have any lengthy mid year holiday seasons though, officially or unofficially.
Other than Easter, the rest of our holidays tend to be moved to the nearest Monday or (not so often) Friday, hence Land of the Long Weekend.
School kids get a longer break at the beginning / start of the year, and if I recall (and it's not changed since I went to school) two shorter breaks during the year of two weeks each I think. Yes, I live within earshot of three schools, you'd think I would have noticed the differences in noise levels during my twelve year stay here. I've not really paid much attention.
I understand Europe has a lengthy period during August, where people bitch about all the tourists coming to their locality, so go to some other European holiday destination to get away from them, and go annoy the locals there.
I may be wrong, but I think USA has their famous school summer holidays, that a lot of movies are made about, which sounds like a lengthy mid year break. The movies are the only reason I know about this. I don't put a lot of stock in the accuracy of anything coming out of Hollywood though.
Other countries, and there are a lot of those, make up their own minds about their holiday periods. May or may not match up with USA, Europe, or Australia, purely coincidentally, or to align with international business needs.
So, some developers are going to miss out on their (northern) summer holidays, and some, even in the north, wont have holidays during that time to miss.
One of the reasons I am loathe to pay for apps. is not because I am a tightwad (although I am). But because I've had 2 paid-for apps broken by Android updates.
Now legally, the developers are responsible - they took my money. However one of these apps simply can't be fixed unless Google reverse the change which broke it.
And since there's no way to revert to the (now "a", the) previous build ...
The best that can be said about Android is that it's free.
Personally I've always felt the pricing structure for apps are not well suited for the environment. It was simply implemented because that's how software was sold at the time, without thought as to what would work best.
The framework they should have rolled out along side regular one time payments is subscriptions, allowing you choose whatever mix of apps you like month to month. By bundling a developer can charge say 10 cents a month for an app, and since the billing is charged lump sum by Google it makes such small charges viable.
I had a few app ideas I wanted to do, but the current payment system doesn't support it. I'm fine with releasing them for free as well but then i have to pay Google an annual fee to do so, and the motivation also takes a hit. It's one area where i feel all mobile platforms failed, zero innovation in terms of payment models.
"The framework they should have rolled out along side regular one time payments is subscriptions"
The subscription model for software is one of the primary things that is ruining software.
" I'm fine with releasing them for free as well but then i have to pay Google an annual fee to do so"
You don't actually. You pay a fee to get into the Play store, but the Play store is not required in order to develop and sell your software.
It's not exactly a unique problem to Android though. For example; I have an iPod Touch, and tried connecting to iTunes a while back. I wouldn't work unless iOS was updated, so I dutifully ran the update. Now half the apps I'd paid for don't work, and even though most have updates, they won't install because they were built for newer hardware.
"However one of these apps simply can't be fixed unless Google reverse the change which broke it"
that is simply not true.... the real fact of the matter is that its not worth the time and effort for the dev to fix it. they have probably released a new app that is "new and improved" and is making them more money that the old one ever will by spending the time to fix it... they just play the SEP card....
"And since there's no way to revert to the (now "a", the) previous build ..."
I am not sure what you are saying here. If you are on about the previous version of android, then for many handsets its just a matter of downloading and flashing to an earlier build.
"The best that can be said about Android is that it's free."
I guess you dont really know much about android if you think the best thing is its free..
the fact that the dev kit is available for free and you are not forced to hand over 30% of what you charge for an app because there is only one place you can market your wares is another.
I am sure other commentards will give you many other good points to android as well as better bad points.....
What's the app?
What's the function that can't be reintroduced?
Is there a single other app anywhere in the Play Store that does the same function (I don't care how, what else, whether it's prettier)?
Because I imagine there's not much that doesn't work in the way you state, when the developer is non-lazy.
Can't speak for that poster, but Android 7.1.1 broke whatever it was which allowed the "ACR" call recorder to work.
Big up for the developer, as they were quick to respond to me and trawl through the debug I provided. As soon as they saw the Android version they replied that it was a change to the API and Google hadn't issued a workaround. If indeed they were going too.
I can't say more than that, as I'm not conversant with Android to that detail, nor to the plethora of apps that exist.
MS did the same between Windows Mobile 6.5 and 7.0. You were able to access the audio stack in 6.5, but not 7.0. Not that the (few) apps that claimed to offer call recording told you that. And that's not including the "call recording" apps which were simply dictaphone apps which you help up to your landline handset and used to "record the call".
To my knowledge, an awful lot of phones have never supported recording calls at all, but that's a hardware manufacturer integration. If they don't present the hardware to the Android drivers, then there's no way for the Android API to record it.
But also note:
"This permission is reserved for use by system components and is not available to third-party applications."
Even the latest Android APIs do have an option to do just what you're talking about, but it's never been properly exposed and officially supported. When you use unsupported stuff, that's what happens.
I don't think it's ANYTHING to do with Android. It's to do with people BYPASSING Android. And I think it's to do with manufacturer's not exposing functionality in a standardised way via the Android APIs that already exist and/or not producing hardware that supports such functionality (e.g. a voice-call-handling chip that doesn't provide the voice data to the processor running Android at all).
"those tests are worth running because Android P restricts access to some interfaces not supported in the Android SDK"
Except no user will have P for at least 6 months after it is "released" by Google. If I couldn't test & fix any issues within 6 months I'd give up programming and go busk or sweep the streets or something.
Millions of Pixel, Xperias, OnePlus and others will have it within 90 days of Google releasing it.
Infact they need to, if they want to stay on the Enterprise Android scheme that promises long term device support (3 years) and patches and OS updates within 90 days of Google.
You know it's not 2014 anymore?
"Except no user will have P for at least 6 months after it is "released" by Google."
Au contraire, anyone owning a Google Pixel/Pixel 2, a Nokia 7 Plus, a OnePlus6. an Oppo R15 Pro, a Sony XZ2, a Vivo X21/X21UD or a Xiaomi Mi Mix 2S could install the P beta on the day it was released (09/05/2018). Since then other devices have been added e.g.the Samsung A3 2017.Plenty of opportunity to test on real hardware well before it's officially released.
Odd for Verizon to update a phone *twice* in it's lifetime.
I know what you mean. In fact, the reason I switched to a Google phone was because Verizon never updated anything other than how much we were charged. Unfortunately, while Google may roll out patches on a regular basis, they have left some arguably serious issues untouched for almost as long as Verizon. I have an old phone or two to play with. I might have to experiment with a roll-your-own solution.
For a beta, already very smooth and pretty well polished, no issues whatsoever, great battery performance (70% by day end, slightly better than Oreo ).
Looking forward to final build, just polish a few rough edges and it's surely good to go.
Still undecided on the gesture nav. Have it enabled, let's see if it's still enabled after a week.....
Biting the hand that feeds IT © 1998–2019