I have built and published my app on Google Play and everything works fine. But I am wondering how I can improve my visibility on the market, how to appear on the first page...
So here is my question,
Do I have to correct every little bug that appears in the Lint Warnings panel (in Eclipse) to be in a better position or is it useless?
I have been looking for resources about that on the web, but I can't find really interesting ones. Do you guys know a good blog that explains how to appear first on the market (or at least, not on the 1234555... page)?
Besides advertising, there are a few useful advices about "how to get your application featured" on this page, basically you have to make a flawless, polished application, which uses a lot of Google API features and is popular among users.
Correcting Lint warnings is good, because it makes your application more stable, but does not directly affect your Market visibility.
If you need more resources, search Google for "getting featured on android market", it might help.
Correcting Lint warnings will make you a better programmer. That's not useless.
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 am attempting to follow the links on the developer console site to implement licensing for my application and am concerned that the docs don't really line up with the current technology. In part of the documentation, I was directed to a page that said the utility for doing this was no longer valid. I am simply looking to get licensing (lvl) setup for my app and am hoping somebody can point me to a good resource.
Here is where I stopped at, as I am not familiar with the whole project library import process. It sounds I need to run a command line to continue the process but I am not sure what one of the values needs to be.
I am not sure what the target ID is or if I just need to update the above mentioned properties file or what?
Docs seem to be a little confusing on this topic, or I've just simply missed the boat.
Thanks!
I have downloaded Android 4.0.1_r1 source code to my local system. I'm working to understand building own custom Android ROM and modify it according to my requirements.
I went through a number of web based tutorials on how to build custom ROMs for Android and I am clear with the overall process. What I'm essentially looking for is a well defined structured way of removing packages that are downloaded along with the source code but not needed for my own version of the build.
Additionally, it would be helpful if someone can provide me links pointing to building android source (guides,books or tutorials) as most of the available resources are based on creating Android APPs using Android SDK and the application framework. Its difficult to find any decent indepth tutorial explaining the entire architecture , source tree and different build guidelines for platform level developers.
This is a good book, but it's not officially out yet (you can get the first few chapters only).
There is no real documentation, but if you hang out with CyanogenMod forums/IRC long enough you can get some insights. You can also ask questions on the official Google Groups, android-porting and android-platform should be helpful. Reading XDA can be helpful too, if you can filter out all the noise.
Generally, the whole thing is quite complicated, and there are parts that are device specific. The only thing that you can remove more or less safely without modifying things (much) are the bundled user-level apps (Calculator, etc). Even some of those may provide some system-level services, so you should watch out.
In short, buy the book, read the groups and ask more specific questions, like 'how do I modify X in order to do Y. I tried Z and it didn't quite work.
In addition to the answer, this is the closest I got to find a suitable information for modifying packages in the source code before building. It also has a decent information for memory optimization.
http://processors.wiki.ti.com/index.php/TI-Android-ICS-MemoryOptimization
For removing packages please refer to the section
Run Time-Volatile Memory Customization
subsection - Customizing Android Product Package
The article pertains to Froyo , but the concepts are pretty much the same Android 4 ICS.
I have added this for anyone seeking reference material on the same.
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.
Doing a bit of advance research, and am stuck on the point summarized
in the title. Namely, is there any way to forward-lock an APK
installed programmatically, from another app? I've not come across
anything beyond a hint in the following post:
http://groups.google.com/group/android-developers/msg/e39941389d4a4cf8
I can't see anything in the docs for PackageManager about forward-
locking, but I readily confess that this is an unfamiliar area of the
SDK for me.
[Cross-posted with the Android-Developers Google group]
If anyone looks at this again... I've since found out that it can't be done in modern versions of the Android SDK. Plus, forward-locking has since been deprecated anyway.