4 ms·

Sure we are using them, but for example the design support library is not very satisfactory. The whole approach of backwards compatibility has not worked out w

Sure we are using them, but for example the design support library is not very satisfactory. The whole approach of backwards compatibility has not worked out well. Google's alternative approach for the last two years have been the Play Services, which are now a behemoth requiring multidex in your app, when the majority just use the API client libraries from them.

GeneralTspoon 11y ago
If you just need some API client libraries then you can compile most modules separately[1] e.g. Ads, Analytics, GCM, etc. This makes Play Services actually usable without multidexing. [1] https://developers.google.com/android/guides/setup#split https://developers.google.com/android/guides/setup#split
Zigurd 11y ago
What I generally recommend for mass market apps is to code for the latest or near-latest API level, depending on features that are useful in new API levels, and to simultaneously or soon after back-port a version using the compatibility libraries for older devices. Note that you can target higher API levels than phones in the the current sweet-spot have by testing for API availability (I.e. use forward compatibility, not just back-compatibility). Depending on the shape of the market, this can be a better alternative for some Android versions than using the compatibility libraries. This puts future development on two, or, for very mature products, on three tracks where you have a code-base for up-to-date devices, and another for somewhat training edge devices, and maybe a third for old devices. Very often new phones have an outsize value to app developers because that's where the new phone customers, who buy apps at a higher rate than people with two-year-old phones. YMMV. If you don't have tens of thousands of users, you aren't going to do it that way. Or, if you app has no need for the latest features, you won't do it that way.

GeneralTspoon 11y ago

If you just need some API client libraries then you can compile most modules separately[1] e.g. Ads, Analytics, GCM, etc. This makes Play Services actually usable without multidexing. [1] https://developers.google.com/android/guides/setup#split https://developers.google.com/android/guides/setup#split

Zigurd 11y ago

What I generally recommend for mass market apps is to code for the latest or near-latest API level, depending on features that are useful in new API levels, and to simultaneously or soon after back-port a version using the compatibility libraries for older devices. Note that you can target higher API levels than phones in the the current sweet-spot have by testing for API availability (I.e. use forward compatibility, not just back-compatibility). Depending on the shape of the market, this can be a better alternative for some Android versions than using the compatibility libraries. This puts future development on two, or, for very mature products, on three tracks where you have a code-base for up-to-date devices, and another for somewhat training edge devices, and maybe a third for old devices. Very often new phones have an outsize value to app developers because that's where the new phone customers, who buy apps at a higher rate than people with two-year-old phones. YMMV. If you don't have tens of thousands of users, you aren't going to do it that way. Or, if you app has no need for the latest features, you won't do it that way.