I know that my question is quite generic and maybe there is more than one approaches to take that decision. But I would like to listen different approaches that maybe I haven't thought since now.
Also, forgive me if stack overflow is not the right place for questions like this (since it is not technical and specific) but I strongly believe that there is not more appropriate place for this question than here. Also I am pretty sure that this subject may be interesting for many android developers here.
So, when I have to make that call, first of all
I consider the official statistics of each distribution. So, I take a look in diagrams like this. Of course we have to keep an eye to the market and to consider very seriously what will be the future of our app one or two years later
A second factor can be the api restrictions, but if you face this problem, sometimes is easier to decide.
Least but not last is the specific market statistics and trends. For instance if the app is paid then you go to more specific statistics, for example Android L users spend more money on google play than the older version users.
All these thoughts became more strong after the release of Android L which is in my opinion the most competitive version against apple. Android L encourages the use of Material Design , contains cool animations and ifrom the point of view of speed , memory management and more technical stuff is way better than the older versions (as it supposed to be).
Thank you
All my apps are currently using api 15+.
Facebook SDK is supporting 15+ api too.
I would use api below 15 just if needed, you have more support and more easy methods to implement your app with 15+.
Well you definitely should install Android Studio and create new project in it. There will be a dialog, which will help you choose a version, giving a percentage of covered devices worldwide.
Related
An application I'm working on was broken by an iOS non-retrocompatible update. It had a big impact on our client's business before we could fix it.
So I'm trying to find a way to anticipate breaking changes in iOS and Android updates.
I've already found:
Apple technical publications: https://developer.apple.com/library/content/navigation/
Android behavior changes:
https://developer.android.com/preview/behavior-changes.html
But it's a lot of reading and I want to make sure every developer in my company knows everything there is to know about breaking changes and that they learn about it as soon as the information is available.
How do you do this kind of technical watch ?
How do you go straight to the useful information ?
Do you know any website or newsletter that might help ?
Thank you a lot for your help.
Update-breaking changes in iOS are rare. That having been said, a few observations:
When there are breaking changes, it's usually in stuff about which Apple has given us ample warning. E.g.,
Apple has started to enforce long-standing counsel about making writing thread-safe code, making sure that certain tasks must happen on the main thread, etc.
Likewise, the shift from 32-bit to 64-bit code base was something that Apple warned us about years in advance.
When Apple says something is "best practice", it's sometimes because they know that failure to do so can result in breaking changes at some future date (usually years down the line). E.g. Apple has advised autosizing masks well before new screen sizes came along. They were advising autolayout and size categories well before split screen multi-tasking was released. Etc.
If they say something is "best practice", they're often trying to help you future-proof your product.
Where possible, stay in the highest possible abstraction in your code. The lower level you implemented your code, the more likely it is to not gracefully handle changes you didn't anticipate. The higher-level the API is, the more likely Apple has taken care of ensuring a graceful transition.
Avoid relying upon undocumented behavior. And definitely avoid anything in direct contravention to the existing docs. (I know it sounds crazy, but there are all sorts of situations where documentation warns you about not doing something even though you might discover empirically that you can get around it.)
Bottom line, if you've empirically discovered some cute technique that isn't documented anywhere, that can easily break. If it's not formally outlined in the documentation, the more likely the behavior is to result in breaking changes.
Watching the "What's New in ..." WWDC videos is a great way to not only discover what's new in every release, but there's often parenthetical remarks about "if you used to do x, consider doing y." Heed those warnings.
I think the WWDC videos are must watch for everyone (esp the high-level "What's New" videos), but if that's too much for your team, divide them up among the team and then reconvene the group and have each person give a 5 minute précis on what's critical.
Every time there is a new release, you should review the release notes, e.g. these should redirect you to the latest docs:
iOS: http://developer.apple.com/go/?id=ios-sdk-release-notes.
Xcode: http://developer.apple.com/go/?id=xcode-release-notes.
The signal-to-noise ratio in these docs can be a bit low, but generally important stuff is covered in here.
Listen to the compiler:
If API has been deprecated, the compiler will warn you. Deprecated API is at risk of being formally removed in future release. If you need deprecated API to support devices running older OS versions, then add run-time version checks, using the API most appropriate for that OS version.
Be wary about disabling compiler warnings. It's quite easy to disregard compiler warnings, or worse, silencing them. If there are any warnings that have been silenced, not only turn them back on, but treat them as errors.
A couple tips for Android development:
Monitor and address deprecation warnings in your build. This is generally a good practice, but especially important on Android. Deprecated methods are an indication that an API will be retired in a future version of the platform. Often this could be an indication that you will soon have to re-write a component in your application.
Make use of the Android support library. This will allow you to implement functionality requiring newer API levels on devices that are not yet at that level. This allows you to code to newer APIs thus helping to future-proof you app.
This is a far-from-complete list. For a much more in-depth overview of this topic see: https://developer.android.com/training/basics/supporting-devices/platforms.html
I just started designing my app for Android L Material theme. I understand that we have to first check whether our existing apps work fine with the ART, the new WebView and all that, but going a step further I want my app to be release-ready when Android L is officially released. But I see that there's very little documentation and I'm not able to get around to find answers to some questions I have -
Is the material theme itself going to be available for older versions of Android?
Is the Android L SDK that's publicly available right now good enough to start building apps using it? I found a few posts on stack overflow where commons guy has said to hold off until Android L is released.
There are a few things that are mentioned in the design specs but there's no documentation on it. Like "Toolbar", for example, is replacing the "ActionBar" according to Google IO 2014 App's source. But why is it not mentioned anywhere in the Android L getting started page? And is it going to be backward compatible with older versions through support library?
Any sample code on how to achieve extended app bar as mentioned in this page?
Is the material theme itself going to be available for older versions of Android?
There have been some comments from Google suggesting that they'll be doing some things in this area. Not everything is strictly possible to offer in the form of a backport. Hence, we won't really know until they ship.
Is the Android L SDK that's publicly available right now good enough to start building apps using it? I found a few posts on stack overflow where commons guy has said to hold off until Android L is released.
The reason for my advice is that we have no idea how stable the L APIs are, particularly with respect to Material Design. If you want to experiment with L for that sort of thing, great! But I'd leave such stuff on a development branch until the next shipping version of Android.
But why is it not mentioned anywhere in the Android L getting started page?
There are lots of things not mentioned in the docs, particularly in API level release notes. That's normal for Android, and it is why I and others write blog posts like this one and this one.
And is it going to be backward compatible with older versions through support library?
That has not been announced. We'll find out when the next production version of Android ships.
Any sample code on how to achieve extended app bar as mentioned in this page?
I am not aware of any, though I haven't been keeping an eye out for it either. My personal aesthetic says "yuck" for that particular aspect of Material Design. :-)
Is "AndroidAnnotations" reliable? I've searched it but couldn't find many articles on it(reviews or tutorials).
I've been considering using this library in my project which already has quite lots of users. Before adopting it, I need a good reputation on it. So my concerns mainly are,
Are there famous products using this library?
Can I say it's stable enough to adopt it for my big project?
Will it be maintained well? (bug fixes, etc)
Thanks in advance.
I am the lead developer of AndroidAnnotations. Let's answer your questions:
Can you rely on AndroidAnnotations?
I think so. AndroidAnnotations is a compile time framework which generates code. The generated code is readable java code, which means that if you need to understand what happens, you can. No magic happening at runtime => you are in control.
We try to maintain a list of external articles / tutorials here.
Are there famous products using this library?
Let's be honest: I don't know. Matthias Kaeppler from Qype talked about AndroidAnnotations at DroidCon London 2011. The frontpage lists the applications that we know for sure are using it. I know there are way more people using it because they ask for enhancements and report bugs, but they usually don't let us know when they publish an app. And of course, the idea of "writing clean and maintainable Android code" is not yet very common in the Android community.
Can I say it's stable enough to adopt it for my big project?
We are using it in our own apps, and we find it perfectly stable. So I would answer yes, but I think you should just try it :-) . Download the 2.2 RC2 (will be released stable soon), follow the instructions and see for yourself. You can do progressive enhancement, and start enhancing only one or two activities. See how it fits you, and let us know if anything goes wrong. And if you do release an app with AndroidAnnotations on the Android market, please let us know, we'll update the front page.
Will AndroidAnnotations be maintained?
Yes, it will. Although it started as a personal project, AndroidAnnotations is now sponsored by a company, eBusiness Information. This company employs people (including me) to work on AndroidAnnotations, with the aim of making it a major Open Source Android framework.
As you can see here and there, we are adding a lot of new features for the 2.2 release. And you won't find a lot of open Defects in the issues, because we concentrate on fixing any bug before adding new features.
I have a published app for Android 1.x and 2.x, and now I want to make it support 3.x.
But Android 3.0 has massive API change, especially on UI, thus if I want to make one app compatible to 2.x and 3.x, the code will be ugly and package file will be huge.
On the other hand, if I make another app for 3.x, then I need to maintain two copies of their common codes. That's really annoying.
What should I choose, or does anyone have a more smart solution? Thanks!
If you package them together you could still maintain everything separately - For example: put a prefix in front of every layout and class for 3.x, such as honeyMain.class, and honeymain.xml
Or you could do it a way that makes more sense for you.
Or keep them partially together.
It WILL make your app larger, but then when 15 people with 3.x download it and 60 people with 2.x download it, you get 75 downloads, instead of 15 for one app and 60 for the other. The 75 cumulative will look better on the apps over all ranking on the market.
On the other hand, if the 3.x is really ugly or FCs, then negative ratings will impact both 2.x and 3.x, but that is easily controlled for by testing, testing, testing.
Also, I personally hate managing code for two different apps. It's overly repetitive.
So, my recommendation is to package them together.
Make use of resource qualifiers, e.g. -xlarge, -v11, etc.
Use reflection where necessary or other techniques to avoid pulling in stuff not supported by API level.
Use the compatability library, that way you can fragmentize your code regardless, avoiding duplication, and with little effort handle different screen sizes.
See providing resources
See multple screens
See compat lib
Right click on your project and select "properties",select "android" from window,and which type of version you want check it and apply
I am new to android and last year i bought two books of android 1.5. But at that time i was busy in my project so was not able to work on android. Now i want to start android again. Should i go for those books or should i buy new editions
Is there any major change regarding basic learnings?
Two books i am having are:-
Pragmatic Hello Android (New addition of this book is available, But still in beta phase)
Apress begining Android (Dont know about this whether new edition is available or not)
Please let me know.
Thanks
EDIT
here i am not asking about the good books of android, as there are lot of questions regarding that. I can find out from them.
My question is purely related to change in version
Should i go for those books or should
i buy new editions Is there any major
change regarding basic learnings?
The vast majority of Android has not changed. However, there are a few subjects, such as support for multiple screen sizes, that did change. You can find out what changed in each release (1.6, 2.0, 2.1) from the Android developer site. If you feel you can get sufficient knowledge of those topics from blog posts, StackOverflow questions, and the like, then you do not need to purchase newer books.
On the flip side, there is very little that a 1.5 book will teach you that is wrong for Android 2.1. The contacts ContentProvider changed, but otherwise there have been few regressions. Most of the changes in these releases are in the form of new capabilities.
Also, bear in mind that it is likely that there will be a new Android release (2.2? 2.5? 3.0?) released at Google I/O in a bit over a week.
Apress begining Android (Dont know
about this whether new edition is
available or not)
Your original edition of this book was really an Android 1.1 book with an Android 1.5 appendix, so that one is particularly old. Of the two books you have now, I would rely on Ed Burnette's Hello, Android more.
There is a newer version of Beginning Android. The same material is also available as The Busy Coder's Guide to Android Development, available as part of the Warescription, written by, um, me. :-)