Hopefully this starts the ball rolling on Android tablet apps. I really love my Nexus 7, but the app selection is definitely inferior to what's available for iOS.
Scrabble on iPad is awesome. Also, please dont mention Words With Friends.
While I'm plugging tablet board game apps, this implementation of backgammon is Awesome. https://play.google.com/store/apps/details?id=com.njsoftware... It regularly wipes the floor with me on higher difficulty levels, and has a lot of really nice features.
Probably because Android has traditionally focused on 7" tablets. Board games are the one area where I wish my iPad 3 was bigger. :(
My understanding is that the android api has improved recently with respect to the ability to support these types of apps, but for whatever reason there's still a noticeable lack of these apps.
Deleted comment
> 5.4. Audio Latency
> Audio latency is broadly defined as the interval between when an application requests an audio playback or record operation, and when the device implementation actually begins the operation. Many classes of applications rely on short latencies, to achieve real-time effects such sound effects or VOIP communication. Device implementations that include microphone hardware and declare android.hardware.microphone SHOULD meet all audio latency requirements outlined in this section. See Section 7 for details on the conditions under which microphone hardware may be omitted by device implementations.
> For the purposes of this section:
> - "cold output latency" is defined to be the interval between when an application requests audio playback and when sound begins playing, when the audio system has been idle and powered down prior to the request
> - "warm output latency" is defined to be the interval between when an application requests audio playback and when sound begins playing, when the audio system has been recently used but is currently idle (that is, silent)
> - "continuous output latency" is defined to be the interval between when an application issues a sample to be played and when the speaker physically plays the corresponding sound, while the device is currently playing back audio
> - "cold input latency" is defined to be the interval between when an application requests audio recording and when the first sample is delivered to the application via its callback, when the audio system and microphone has been idle and powered down prior to the request > - "continuous input latency" is defined to be when an ambient sound occurs and when the sample corresponding to that sound is delivered to a recording application via its callback, while the device is in recording mode
> Using the above definitions, device implementations SHOULD exhibit each of these properties:
> - cold output latency of 100 milliseconds or less
> - warm output latency of 10 milliseconds or less
> - continuous output latency of 45 milliseconds or less
> - cold input latency of 100 milliseconds or less
> - continuous input latency of 50 milliseconds or less
> Note: while the requirements outlined above are stated as "SHOULD" for Android 4.1, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these requirements are optional in Android 4.1 but will be required by a future version. Existing and new devices that run Android 4.1 are very strongly encouraged to meet these requirements in Android 4.1, or they will not be able to attain Android compatibility when upgraded to the future version.
> If a device implementation meets the requirements of this section, it MAY report support for low-latency audio, by reporting the feature "android.hardware.audio.low-latency" via the android.content.pm.PackageManager class. [Resources, 37] Conversely, if the device implementation does not meet these requirements it MUST NOT report support for low-latency audio.
When bored I'll browse to see if there is a new app, but it is always the same. Sales are bad too as I generally have purchased more than 85% of what Google decides to put on sale.
For real drawing, Adobe Photoshop Touch https://play.google.com/store/apps/details?id=air.com.adobe.... Autodesk Sketchbook Pro https://play.google.com/store/apps/details?id=com.adsk.sketc...
For simple and very responsive line drawing, Quill https://play.google.com/store/apps/details?id=com.write.Quil...
If your use case is more diagrammatic, try Skitch https://play.google.com/store/apps/details?id=com.evernote.s...
There's still definitely space for a proper drawing app on Android.
-Again, the documentation isn't well-written. It almost all feels like it's written either by an engineer with little writing experience or a technical writer without engineering experience. There have been times when I've had to re-read passages over and over again because I genuinely couldn't parse what they were trying to say.
-The insistence on weak typing everywhere is insane. Intents are sloppy, weakly-typed junk; Messages ditto. The R auto-generated class isn't bright either--even if you need an integer index, at least wrap it in a type-safe class to eliminate the possibility of passing the wrong thing around. I really do genuinely like working in Java, but I like working in well-designed Java. This is the same company that made Guava, which is perhaps the most elegantly designed API I know of in Java-land. But many of Android's APIs treat classes as an incidental hindrance.
-Dalvik blows. There is nothing good about it and there's so much that's bad about it. The class limit is crippling, and the lack of hot-loading is prohibitive. (I write games in my spare time, I'd love to be able to use Groovy as a scripting layer, but that's not going to happen.)
-This might sound crazy, but XML is a machine-readable format. People know that, right? Okay, great. So why are the tools for building layouts so much junk?
Not on this list is fragmentation, because I don't find that to be a real problem for my purposes. My app for work is 4.0+ only, and I test on a Galaxy Nexus; if it works there it'll work on a SIII or an Atrix HD or whatever else somebody wants to try. (We're outsourcing wide device testing to uTest, but our app isn't done so I haven't had the opportunity to try their services.)
I've been working with the Android SDK for a few years now, and I haven't found any of the things you mentioned to be a major hindrance.
Personally I think the documentation is just fine - Perhaps I haven't been poking around the same corners of it that you have, but the tutorials have always been helpful and the design guide is very good.
The weak typing is again an annoyance. However in all my time I can say, that I have only run into one bug that was caused by weak typing and that was on the R auto-generated class. Typically your strings are a R.strings, colours are at R.colours, etc so it makes it pretty easy to spot if you are passing a string through where you should be passing a colour.
I did java dev back in the 1.1 and 1.2 days - now that JVM sucked! Dalvik, again I have never had any problems with.
As for the GUI design tools, they are probably some of the best I have seen. Definitely better than the tools that I was using to do Swing dev work back in the day.
So yes, all those things you mentioned could do with some more polish. But I have found my Android dev experience to be good one and the android SDK is more than adequate to develop some pretty hefty apps!
Here's the problem. Say you need to pass around a specific resource (reusable code somewhere in your app):
void doSomething(int stringResourceId)
^ THIS IS WRONG
And comparing the GUI design stuff to Swing is ignoring the ridiculous number of vastly better systems everywhere else. SWT is great. Microsoft, too, nailed it with WinForms and WPF/XAML kick an unreasonable amount of ass (though I won't use it because, derp, Windows). Swing sucked from day one.
Your post disagrees with me, and that's fine, but I get a vibe of "good enough" out of most of it and we should, as a culture, be better than that. Android isn't. It is precisely "good enough," and that sucks because the Android people are obviously very smart people who could be doing vastly better.
* I really like that the OS can handle so much of the scaling and resizing for you as you move from a 3 inch phone all the way up to 10 inch tablets
* I think google is to be commended for building an eco-system that involves so many different hardware devices, manufacturers, etc
* The latest look and feel in 4.1 and 4.2 is turning out really well. A well designed android app looks great [1][2]
* The intents system and the way you can link together different apps is very innovative. I wish iOS would copy it!
* Android is evolving at a really rapid pace.
There are some bits that are 'good enough'. You mentioned many of them. They get the job done, but are not necessarily the best way of doing things, or they need plenty more polish. I would add one thing to your list: performance. Project butter still has helped, but android still feels nowhere near as performant as the apple devices.
Finally there are some bits with just plain suck. Google HAS to do something about the upgrade story on existing devices. They can add features and optimise existing code until they are blue in the face, but it isn't going to do them one iota of good if 95% of the devices out there will never see the updates!
[1] - Checkout Instapaper and mint here. IMHO they look really good: http://developer.android.com/distribute/googleplay/spotlight...
I think google is to be commended for building an eco-system that involves so many different hardware devices, manufacturers, etc and Google HAS to do something about the upgrade story on existing devices.
Disagree on the first part, for one really big reason: the overwhelming majority of those manufacturers are anti-consumer assholes. Like, I would personally much rather that literally-literally every manufacturer who ship with a locked bootloader or who refuse to commit to three years of updates be blocked from using the Google apps on any of their devices (which is why I included the second bit). I realize Google will never do that, and the "screw you, this is how you do it right" attitude of the Nexus line is an okay "toe this line" approach, but I don't think it's sufficient.
The intents system and the way you can link together different apps is very innovative. I wish iOS would copy it!
The idea behind the intents system is groovy. The implementation is terrible. Intents external to my application are great, barring API problems. But within my application--I get the reason, intents are bad for this sort of thing because the information you can pass around is limited and not typesafe. You end up with global state or a lack of type safety and neither option makes me not want to throw things. I think I'd rather see the Activity model be more object-oriented--like, have startActivity() actually take an Activity and allow you to define a constructor.
The single thing that almost got Google into big trouble with Oracle is a weak point ;)