61–70 of 118 posts
After porting VLC on so many platforms, to be honest, working on Android applications is not too bad. Notably compared to other mobile platforms. The tools and IDE are quite good (they need a lot of RAM though), the deployment is easy, the development workflow simple enough and the devices are easy (and cheap) to come by. Even the Play Store console is not catastrophic. A contrario from Youtube, you can get questions…
Earlier quoted context omitted.
I compare that to Windows which has been around two decades longer than iOS and Android and which APIs have remained remarkably stable and backward compatible. It is possible to do it. It is just more work.
Well, to be fair, this comes at the cost of Windows (like other major desktop operating systems) being considerably less secure than Android or iOS. This tradeoff is not easy to avoid except by designing the permission model to be sane from the start, and we all know that good upfront design doesn't exist.
My annoying use case for those was ebook readers - I have a pretty massive library of epubs (Thanks Baen Webscriptions!) and have tended to just dump a ton of them into a folder in storage on a device. I can then pull those up in CoolReader, Moon+ Reader (position sync!) or FBReader as I desire. On Windows Phone every reader app (not that there were many) had to have its own independent download because god forbid you have shared freaking storage.
Somehow I feel that this is also going to end up hitting things like third-party gallery apps such as ones that allow tagging, along with the multimedia stuff that other folks are concerned with. Oh, and music. The death of MP3s saved locally to a device and used by multiple apps?
So much of what Google has been doing with Android (turning it into a minimal platform for running the massive Google Play where all functionality lives) seems like they're heading down the walled-garden that Apple has always been, but with creepy monitoring and ad-driven revenues layered on top.
I always dismissed iOS as an option because I didn't like how locked-down it was and I really liked swipe-based input, but now that iOS allows keyboards and the locked-down aspect is happening everywhere perhaps it's time to reconsider.
Edit: removed disparagement of Windows Phone apps
I don't really mind that some behaviors are being restricted. (Although I think removing the ability for apps to toggle WiFi is nonsense.) The problem is that Google wants to break API compatibility without actually calling it what it is. Your app, which worked for years, is now broken and as far as the user is concerned it's your fault. I've been tempted to set the "max API level" property on my apps so that I don't…
>reasonable deprecation timeline Each new Android version starts with a beta which previews and advertises the behavior changes, how is that not a reasonable deprecation timeline ? (real question, not trying to be cute) > don't let users install apps that target old API levels Google has been less active on that front that I would like but the play store is starting to at least enforce that new apps and update must t…
Testing against betas can cause regressions for non-API reasons. That's why I'm reluctant to test against them, preferring to wait for final releases.
For apps that need maximum stability with minimal effort deprecation policies have to preserve BC at least for one release cycle.
Android's Storage Access Framework is really underrated. Just ask the user to choose a document (file or image or whatever) by firing an intent-- then Android's built-in file picker starts up and you don't have to deal with implementing any of that UI experience. After the user picks the file, a content:// URI is returned back. https://developer.android.com/guide/topics/providers/documen... Best part-- along with the…
> Reading from the content:// URI is a little different than from a file:// I haven't found the reading part to be different, but getting the uri has changed from Uri.fromFile() to their FileProvider package. Which, requires quite a bit of setup in comparison. To be fair, it's documented well on the Android developer site.
[0] https://developer.android.com/reference/android/media/ExifIn...
Earlier quoted context omitted.
The file manager would ask you to pick (using the Android UI, via SAF) the directory where you had downloaded the zip, then everything would work the same. Alternatively, the app can register itself as opener of zip files, then it could extract them freely to its own private directory (without asking for permissions) and let you list and upload them.
This is all a load of crappy workarounds leading to a convoluted and cumbersome user experience. From a usability perspective, I would not consider such a behavior a solution.
Android's Storage Access Framework is really underrated. Just ask the user to choose a document (file or image or whatever) by firing an intent-- then Android's built-in file picker starts up and you don't have to deal with implementing any of that UI experience. After the user picks the file, a content:// URI is returned back. https://developer.android.com/guide/topics/providers/documen... Best part-- along with the…
The SAF APIs are cumbersome garbage up there with Account Manager and ContentProviders. Its missing important providers like DropBox, and even Google Drive doesn't implement it completely.
Earlier quoted context omitted.
Sorry to hear that. What do you do nowadays?
Just only release for iPhone :)
An iPhone may be more "locked down" than an Android equivalent in terms of what you can install, but when the App store is so robust, you really don't feel any pain from the walled garden.
An iPhone user doesn't need to side load a bunch of software to get the job done -- the App store has high quality tools for 99% of use cases and most are available for a couple bucks.
Earlier quoted context omitted.
People use older devices.
https://developer.apple.com/support/app-store/ 80% of all iOS devices are on iOS 12. An additional 12% are on iOS 11. Any device that can run iOS 11 can also run iOS 12. By not supporting older devices, you are missing out on at most 8% of the iOS population. But even some percentage of those are able to update to iOS 12. To target anything older than the 5s means you also have to target 32 bit processors. How much t…
You'd better believe there are older devices out there, and people would use the app store with them, iff the app store would only show you apps (or versions of apps) that still run on your device.
It is frustrating trying to get games on an old iPad for the kids.