My Code is Fragmented - Android Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > My Code is Fragmented - Android Development Megathread

«‹›3 »

Doctor w-rw-rw-: Jun 24, 2008

Late-night braindump (tell me if I should clean this up):

duck monster posted:

Does android support in-app purchases. Got a client who wants to know.

http://developer.android.com/guide/market/billing/billing_overview.html

Yes, and last time I looked into it (1+ years ago) it sucked. Maybe it's gotten better. Google is phasing out alternative forms of payment. Obviously, it's harder for Google to have a handle on it than Apple, but they plan - eventually - to pull the same my-way-or-the-highway poo poo that Apple did for mobile payments. So even if there is an alternative, you should factor that in - unless you're planning on releasing on an alternate platform, in which case YMMV.

Glimm posted:

What is Android?
Google�s quirky, beautiful, mobile operating system.

Glimm posted:

Learning Android

Android Design - Know and use Android design patterns. Don�t be a schmuck.

If you�re interested in developing for Google TV there is Google TV specific development information available.

Newbie Android developers should consider that while there *may* a time and a place to violate the design patterns, if you don't know when, then that is not the time. Most of the time you're probably just going to end up with a crappy app. And while you might think you can just port your tablet layout to GoogleTV, remember that TVs don't have touchscreens, have up to 10% overscan on the edges, are navigated with the D-pad and not usually the mouse, and the option button is practically taboo.

Glimm posted:

Useful(?) Tools, Libraries, and links

ActionBarSherlockYou no longer have an excuse to forego the ActionBar. Well, unless the lovely iOS port your boss is paying you to make can�t really utilize its features. In which case, I�m sorry.

RoboGuice - Google Guice is a dependency injection library for Java projects and RoboGuice is the Android specific version of the library. Give it a try, if for nothing else but to use the improved logging functionality it offers. Can greatly reduce boilerplate code.

AQuery - Android-Query (AQuery) is a light-weight library for doing assynchronous tasks and manipulating UI elements in Android. Can greatly reduce boilerplate code. The AQuery blog has helpful usage examples as well.

Android Annotations - (recommended to me but haven�t used) adds interesting annotations like @UiThread to ensure a method is run on the UI thread.

greenDAO - (recommended to me but haven�t used) maps POJOs to SQLite database tables.

Android Asset Studio - generate icons and images at proper sizes given a source image, even has a 9 patch generator.

ActionBarSherlock is a must. Like, any new project that doesn't want to be irrelevant must use it. This goes hand-in-hand with following the Android design patterns. It follows that the Support Library is a must. USE IT. Fragments are a good idea, but you don't necessarily need to start with them right off the bat. They're basically activities minus the baggage of having to be the only thing on the screen. Bags of self-contained logic and UI, that's what they are.

WARNING On some older devices, with enough injection bindings, RoboGuice may contribute noticeably to the startup time of the app. Use something like RoboSplashActivity if you're targeting old devices, more bindings will mean a longer startup, but old ones are seriously slow. Also note that constructor injection makes a lot less sense on Android, and that immutability and anything referencing a context needs to be handled with care.

I would not use AndroidAnnotations in production code simply because it's too far off the beaten path that I anticipate debugging could be a bitch. IIRC, it uses annotations to transform the source. While it might seem nifty, I don't want to have to pretty fundamentally alter my code if there's a bug I can't locate or figure out how to fix. That said, I'm not actually aware of any reason the implementation is not sufficient.

I haven't seen greenDAO before, but be careful when displaying large lists of objects backed by POJOs it's going to put some memory stress on your app, and it could hiccup. If you have a large set of data that maps well to SQLite, consider using a SimpleCursorAdapter. it will often be smoother than an ArrayAdapter will be.

Miscellaneous:

Remember that activities are destroyed and recreated on orientation change.
An asynctask can run, then finish independently of an activity. It'll probably crash the task with an exception if it references the activity. However, this usually doesn't affect the activity anyway.
RoboAsyncTask/SafeAsyncTask are useful because AsyncTasks have awful exception handling and silently drop Exceptions. onSuccess, onException (forgot if that was the right method name but you get the idea), and onFinally make handling errors so much easier.
Use ACRA If you want a non-poo poo way of finding out about your errors. Android market is frustratingly bad about detailed information.

Doctor w-rw-rw- fucked around with this message at 09:37 on Jun 18, 2012

# ¿ Jun 18, 2012 09:08

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 12:22

Doctor w-rw-rw-: Jun 24, 2008

Glimm posted:

Done.

Also, did anyone notice the developer.android.com redesign?

Yes. It's horrible. Less readable.

# ¿ Jun 23, 2012 03:25

Doctor w-rw-rw-: Jun 24, 2008

Glimm posted:

Odd, I find it easy on the eyes. What I really like is the ActionBar styling and the autocomplete in the search box, just looks pretty to me.

It's easier on the eyes but I feel like that's part of the problem. I could scroll very quickly through the old documentation and know roughly where in the document I was just by the shape of the text. Now not only that's harder, but the links to other pages don't pop and so it's easy to miss. I hate how muted it looks now.

And it's poo poo like this:

that means that I can no longer code by dividing my screen in half, because why would I ever want to see the diagram and the code at the same time?

They also got rid of the toggle that made the page stop complaining about your API version so that when you googled for something related to, say, fragments and it brought up the normal fragments, you could click it off and find what you were looking for anyways, because the API is the same as in the support library, then click it back on so you can browse the docs as usual for the rest of the API.

# ¿ Jun 23, 2012 06:47

Doctor w-rw-rw-: Jun 24, 2008

Sinestro posted:

It is 2012, get another monitor. You can get a real, 1440p IPS 27" for literally 300 bucks. There is no excuse.

I suffered from neck problems when I had two monitors. Totally went away when I switched to one huge monitor instead. (though that screenshot is from my laptop not my work computer)

# ¿ Jun 24, 2012 00:18

Doctor w-rw-rw-: Jun 24, 2008

Lutha Mahtin posted:

What is the least-ugly way of writing SQL for Android in Eclipse? Right now I'm putting each statement one-per-line in my strings.xml file like this:
XML code:
<string name="MicroJobsDatabase_onCreate">"
CREATE TABLE jobs (_id INTEGER PRIMARY KEY AUTOINCREMENT, employer_id INTEGER, title TEXT, [...]);
CREATE TABLE employers( _id INTEGER, employer_name TEXT, contact_name TEXT, website TEXT, [...]);
[...]
"</string>
and chopping the lines into an array of Java strings. However I'm pretty sure I will screw something up, either through mis-escaping something or misreading what I've written due to not using whitespace like I always have with SQL.

(code stolen from here)

You could put your .sql files in the assets directory and write a class to load your SQL from that. I implemented migrations that way.

# ¿ Jun 25, 2012 21:41

Doctor w-rw-rw-: Jun 24, 2008

Lutha Mahtin posted:

Does this involve writing like, half of a SQL lexical scanner? In the book I'm reading, the methods used to pass statements to SQLite (e.g. execSQL(String sql)) accept one statement at a time, so since I want to write .sql files with nice indentation and whitespace it seems I'd need to have a more complex tokenization process than my current scheme of String.split("\n").

Quite possibly. I don't remember how exactly I solved this problem since it was about a year ago or so and it never made it into production. Having a sqlite database file rather than a list of queries to create the database might have been how I did it, but that doesn't lend itself to migrations, though I've always found it easier to just dump the database since I use it as a cache and people are jerks and wait for several versions before updating for no reason.

# ¿ Jun 27, 2012 20:03

Doctor w-rw-rw-: Jun 24, 2008

TheReverend posted:

Hey dudes, I'm coming from an exclusively C# workplace and I'm having some XML issues. In .NET, XML that was formatted like a datatable was pretty easy to sort through, edit columns, add columns, edit rows, delete rows, add rows, etc.

I can't find any nice easy-to-use class within the Android SDK.
Is there anything I'm missing?

Perhaps http://code.google.com/p/lambdaj/

Expect for it to be slow as crap. Reflection on Android was super bad before 3.0, and is still slow in general, which means that 75% of your potential users are probably going to feel the performance hit. I haven't used it myself.

# ¿ Jul 3, 2012 18:50

Doctor w-rw-rw-: Jun 24, 2008

kitten smoothie posted:

How is a screen like this implemented - as a sectioned ListView? The map is not live, it is a static image presumably generated by Google's static map API.

I did something like it by writing a custom arrayadapter and overriding getItemViewType, getViewTypeCount, and getView. I ended up with a little messy (but as clean as could be reasonably expected?) hack that required some hacks to make context menus or listfragments work, but I forget how much of this was also because I needed a special view type at the bottom for lazy-loading.

# ¿ Jul 7, 2012 10:07

Doctor w-rw-rw-: Jun 24, 2008

Harold Ramis Drugs posted:

Which one should I modify? Also, the book doesn't say whether to append or overwrite. Should I append or overwrite?

Overwrite the layout one.

"com.deitel.cannongame.CannonView" is a type of view. So is RelativeLayout (it's a ViewGroup actually), and so is TextView. Non-android views have to be fully qualified with the package name, hence com.deitel.cannongame.

# ¿ Jul 22, 2012 05:28

Doctor w-rw-rw-: Jun 24, 2008

Flash18 posted:

I'm hoping someone here has some experience with HttpUrlConnection, which is causing me a lot of aggravation. The API I'm using insists that that my request needs to use basic authentication, which I assume I'm using properly, as I've just copied to exactly from HttpUrlConnection's page in the API.

None-the-less, I keep returning an IOException any time I try to read the response, with the details being "No authentication challenges found".

I fired off a quick request using curl on the command line, encoded correctly, and the server gave me a correct response.

I tried HttpClient, but I couldn't work out how to use basic authorization with it, but I got a "Not Authorized" response as I expected.

Using an incorrect url in the request will give me 404 error.

I'm assuming now I'm either doing something horribly wrong, or something is up with their server and I need to use preemptive basic authentication. I haven't found anything helpful on preemptive authentication on google, everything I tried still results in the same error.

A quick google reveals http://stackoverflow.com/questions/1968416/how-to-do-http-authentication-in-android

Also, Google don't give a gently caress about HTTP Basic Auth. :argh:

# ¿ Jul 24, 2012 19:06

Doctor w-rw-rw-: Jun 24, 2008

NoDamage posted:

The Android emulator is super slow as is, I can't even imagine how much slower it will run inside a virtual machine. What you can try instead is installing Android-x86 in another VirtualBox and running Android directly on that, rather than using the emulator inside a VirtualBox. (I do this anyway because it's so much faster than running the emulator natively.)

You realize there's official x86 emulation now, right?

# ¿ Aug 4, 2012 09:31

Doctor w-rw-rw-: Jun 24, 2008

PT6A posted:

I ended including the database as a resource, and copying it into the proper location on first run. It's not ideal, especially if you've got a large database, but it does work.

Why resource and not an asset?

Put it in your SQLiteOpenHelper or whatever it's called, and apply it at database creation or update time. Or something like that.

# ¿ Aug 7, 2012 11:04

Doctor w-rw-rw-: Jun 24, 2008

BabyJebus posted:

Do something like this...

code:

private ProgressDialog progress;

private void doFirstRun() {
   SharedPreferences settings = getSharedPreferences("PREFS", MODE_PRIVATE);
   if (settings.getBoolean("isFirstRun", true)) {
	progress = ProgressDialog.show(this, "First Run", "Creating player database and adding players").show();
	new AddPlayersTask().execute();
   }
}

private class AddPlayersTask extends AsyncTask<Void, Void, Void> {
	@Override
	protected Void doInBackground(Void... voids) {
		addPlayers();
		SharedPreferences.Editor editor = settings.edit();
       		editor.putBoolean("isFirstRun", false);
       		editor.commit();
		return null;
	}

	@Override
	protected void onPostExecute(Void v) {
		progress.dismiss();
	}
}

Shouldn't the progressdialog be a member of the asynctask and be started in onPreExecute?

# ¿ Aug 10, 2012 09:08

Doctor w-rw-rw-: Jun 24, 2008

rotaryfun posted:

I'm getting:
Type mismatch: cannot convert from void to ProgressDialog

Would this be why?

edit:
I changed it to
code:
protected void onPreExecute() {
   progress = ProgressDialog.show(this, "First Run", "Creating player database and adding players").show();
}
Now I'm getting:
The method show(Context, CharSequence, CharSequence) in the type ProgressDialog is not applicable for the arguments (ViewPlayers.AddPlayersTask, String, String)

edit2:
Nevermind, I added changed the context from this to ViewPlayers.this (activity name) and it cleared the error.

edit3:
Got it all up and running. Works great. Thanks for the code help gentlemen!

are you not using an IDE to edit? You should be able to autocomplete most of that in seconds.

# ¿ Aug 10, 2012 18:45

Doctor w-rw-rw-: Jun 24, 2008

Zero The Hero posted:

Hey guys, looking for some advice here. I'm trying to do some type of persistent data storage in my app, and after looking around, I decided a FileOutputStream( http://developer.android.com/reference/java/io/FileOutputStream.html ) would probably be best for me. Right now, all I have is a LinearLayout with a series of CheckBoxes. I just need an efficient way to save the data, which is the only way a checklist is ever going to be useful.

As it is right now, my xml file contains all the CheckBoxes, and my java file is pretty clean. I know I'm going to need to read in the data and set the initial states of all the CheckBoxes in the onCreate() function and save in the onPause() and onStop() functions. I assume I could, in each of these functions, address each CheckBox by id and update the info that way. But that's not a good solution, since every time I decided to add a new CheckBox to the cheklist, I'd have to update the layout file, as well as three separate functions in the java file. I was hoping there would be a way to just read every box in sequence and write the whole thing to a file. My C background is telling me to throw them all in a struct and read/write the struct to and from a file each time, but something tells me that's just not going to work here.

You should be able to hook checkboxes up straight into SharedPreferences. I could be wrong, since I haven't done anything like that in a while, and it might have been a function of a PreferencesScreen, but you should probably use SharedPreferences regardless, if it's a mostly static set of checkboxes. Otherwise I dunno.

# ¿ Aug 10, 2012 22:16

Doctor w-rw-rw-: Jun 24, 2008

PT6A posted:

I'm trying to get Eclipse and the Android SDK set up on my laptop. I think I have everything installed properly, but Eclipse and/or ADB will not recognize my phone or my tablet (which are working perfectly with my main computer). I've installed the whole thing on OS X computers successfully multiple times, but this is my first time with a Windows machine, so is there some magic step I'm forgetting? I installed the USB driver for my tablet, but it still won't work.

EDIT: Never mind, the right combination of restarts and unplugging/plugging it in finally got the prick working. I still have no idea why it wasn't working, or what I did to fix it so I can't help anyone else in a similar situation, but the important thing is that it's working now.

adb kill-server && adb start-server often helps, 'cause it kills and restarts the daemon that connects to the Android devices.

# ¿ Sep 4, 2012 20:33

Doctor w-rw-rw-: Jun 24, 2008

Sab669 posted:

I'm bashing my head against the keyboard in my iOS class right now because I hate obj-C. Was just digging through the iOS programming thread here and I saw a "C# / .NET for iOS" framework you can buy.... Then I saw it's available for Android too. Has anyone tried it? I really want to do Droid development, but I strongly dislike Java for no good reason other than I'm unfamiliar with it and Eclipse.

Re: Mono:
Note: I haven't used Mono, though I have looked into it at work.

You're just trading the devil you know for the devil you don't. Both in terms of iOS -> Android, and in terms of switching to C#. Not that there aren't good reasons for switching, but you also indicate that you hate Objective-C and dislike Java. For the most part, hating on any kind of language quickly becomes trite and repetitive, and doesn't stop people from using them and writing decent software with them. Even PHP, as awful as it is, has a lot of software, some of which is very well-constructed.

Apologies if this comes off as rude, but allowing language hate to dictate your choice of platform is an awful thing to do. Languages are languages. No matter how good a language you use, awful tooling or libraries will ruin it.

As I understand it, C# is, if not in code, then at least in character, very similar to Java, though with a couple of nifty features thrown in and some lessons learned from Java. There's little to nothing fundamentally different in Java, Objective-C, and C#'s flavor of OOP; or rather, it's so similar that Mono can bridge C# to both fairly competently. Nothing is stopping you from trying Mono if you like C#, but keep in mind that your framework is a second-class citizen subject to breakage, and the languages are the least of your problems if you plan to do anything "real" with either platform. Platforms (the sum total of considerations involving available libraries and frameworks and device limitations) are what will dictate how good or bad of a time you have (hint: Android can be pretty bad, usually far worse than iOS).

Also, since you won't be going beneath that abstraction directly, you may encounter unusual difficulty with debugging problems that come up.

Re: Scala:
Scala is going to be strictly worse than Java on Android. Slower, less tooling there, more finagling with bullshit other than just writing an app, which is already tough enough as it is. Not for the faint of heart, if you ask me. The language is good, the libraries are good, but the performance is worse. If nothing is particularly performance-dependent, you'll be in better shape but you're going to have major problems with building the app. Proguard has issues with Scala, and you'll be including a large jar containing the Scala runtime library.

I haven't looked too far into Mirah, but since it can compile its source into Java source, and has no runtime library, it might be easier to debug than Scala.

# ¿ Sep 26, 2012 01:32

Doctor w-rw-rw-: Jun 24, 2008

Mr. Crow posted:

This thread doesn't see much activity... is Android that bad to work on or what?

Yes, if you ask me:

I posted:

Mr. Crow posted:

Somewhat related, going to start trying my hand at Android development, is Eclipse + the Plugin the prefered way or is there an IntelliJ equivilent? I use Resharper at work and absolutely love it so I feel comfortable just jumping in and buying it, JetBrains does good work. Not really a point though if it's going to be a huge hassle to work on Android stuff in IntelliJ though.

Eclipse + ADT is the only "supported" method, but you can try your hand at IntelliJ. It's a hassle no matter what, anyways.

# ¿ Sep 28, 2012 20:55

Doctor w-rw-rw-: Jun 24, 2008

Android-unused-resources is great. However, and without trying to paint the strokes too broadly, I'm going to go out on a limb and say most of us don't use most of these extra libraries if we do Android for a living. Have you tried building an app with lots of libraries? Here's what can happen:

* The apk is positively ginormous. Users bitch, because they want to store apps on their SD card.
** You added a widget or some other crap that disqualifies your app from being moved onto their SD card. Users bitch some more.
* The apk takes forever to build. Your build times are now approaching three minutes, if you build it from eclipse because packing it all into classes.dex takes forever, and it doesn't run proguard on debug releases, so instead of 800 classes your apk will have sixteen THOUSAND. Added Joda-time because you realized how broken Java date/time classes are? Congratulate yourself with another several megabytes!
* You add ActionBarSherlock as a dependency. So far you're still traveling on the beaten path, so it's iffy but everything works.
* You add proguard. It strips too much, but you don't notice immediately, because your apk is now much slimmer (but most users actually didn't notice or care). Your app is broken and you might or might not realize it, depending on how thorough your pre-market-push routine is.
* You added proguard. You decide to upgrade to a newer version which works better.
* You updated proguard, but had to switch to ant to get it to pick up the newer tooling. That's okay, because it's officially supported with the android tool (android update -p blah blah blah). Things seem to work, but you tweaked build.xml.
* Android tools update. You decide to update. Guess what? they changed the directory libraries go in without telling you. It's now libs/ instead of lib/.
* You start getting non-deterministic build failures. Proguard is often to blame. You disable it. You still get non-deterministic build failures, but of a different type and for other reasons. Whatever. You turn Proguard back on.
* You switch to maven. Eclipse hates you.
* You tweak your project so it works, by creating a local maven repository directory structure, which surprisingly, works.
* You add a library. You try updating the project configuration. Eclipse hates you.
* You switch *back* to ant, and just run "ant clean && ant clean && ant clean && ant release". If that errors out, you run "ant release" once more. If that errors, repeat.

Bonus:
* This journey of one and a half years slowly drives you mad, culminating in desperate cries for sympathy in the technical section of an online forum with people likely to understand your pain.
* You realize that yesterday, after work, your mind drifted to Android and you started tearing up without even realizing it.
* You realize that you, over the course of the last three years, have transformed from that cocky developer :smug:

into

# ¿ Sep 29, 2012 03:22

Doctor w-rw-rw-: Jun 24, 2008

Thermopyle posted:

Awesome and accurate-ish. I don't do Android for a living, but I think I've touched all of those problems at least once.

I mostly solve the Android headaches by not caring about anyone not running a new Nexus device!

Sorry for going nuts, though. I love my company, love its people, and believe in what it's doing (online video streaming), but sometimes I really just feel like I need to find another job. I was hired as an iOS developer, hah. Android work was going to be "temporary", while we were waiting on a couple of external factors.

Anyways, I'm gonna stop now since my Android rage is spent for now (It'll come back quick I'm sure) and work must go on.

The takeaway, though, is that Android is a platform best targeted at hobbyists, large companies, or lifestyle companies - i.e. either scale down the engineering to only handle the latest/easiest platforms or scale up engineering to handle as much as possible. An Android team of one working on a serious app that reaches a lot of people is going to either sacrifice quality or have some brain-breaking problems in all cases.

Doctor w-rw-rw- fucked around with this message at 09:02 on Sep 29, 2012

# ¿ Sep 29, 2012 08:57

Doctor w-rw-rw-: Jun 24, 2008

Glimm posted:

Yeah it's pretty awesome. Before an official x86 emulator was around I'd sometimes use the Google TV emulator just to mess with something where the speed wasn't abominable.

In Android news for the day Android's new build system has been officially announced and is at version 0.1, yay!

https://plus.google.com/109385828142935151413/posts/XnW7t9XJCMJ
http://tools.android.com/tech-docs/new-build-system

Wow. This is like a laundry list of stuff I needed years ago.

BuildConfig
Product flavors
Binary library projects
Package name overrides
etc.

# ¿ Oct 3, 2012 00:49

Doctor w-rw-rw-: Jun 24, 2008

TheReverend posted:

Has anyone here used the In-app Billing with much success? I admit I'm still pretty new to android and that stuff I've done hasn't been too complicated but this In-app stuff seems like a design disaster. I'd have thought it would have been a whole lot easier!

Is it really this complicated, or do I just suck?

If Android -> assume design disaster.

I think I dabbled in it once upon a time but didn't get too far into it. If it were me I'd just integrate with Stripe or something.

# ¿ Oct 16, 2012 01:49

Doctor w-rw-rw-: Jun 24, 2008

Geekner posted:

I keep running into convenience functions that were added in API 8/9/11. I hate spending time re-implementing poo poo that should have existed in API 1.

String.isEmpty() - added in API 9

gently caress.

There should not be twice as many phones with 2.1 than 4.1.

Oh man, String.isEmpty. I remember that one well and my mind instantly went to it before I got through the first sentence.

Why, you ask?

Ask the thousands (tens?) of users who complained. :cripes:

I vowed to always test with the lowest API first.

Use TextUtils.isEmpty, btw.

E: link

Doctor w-rw-rw- fucked around with this message at 11:14 on Oct 16, 2012

# ¿ Oct 16, 2012 11:11

Doctor w-rw-rw-: Jun 24, 2008

Flobbster posted:

In fairness, you can go straight to the source and blame Java for that one, since they didn't decide that isEmpty() might be useful for strings until 1.6

The current state of fragmentation on Android is ridiculous though. I use Android in my data structures course and I hate that I still have to use 2.2 as my baseline for all the projects because that's what most of my students still have. And it really pisses me off that we bought a batch of Samsung 7" Galaxy Tabs last year for classroom use and we can't even upgrade those (officially) past 2.3.

The only reason I can tolerate programming in Java anymore is because of Android, and I'm excited about when they finally get around to adding lambdas (maybe in Java 8?). But what are the chances I'd be able to use those on Android if I can't upgrade it? Not much, unless their implementation is all compile-time transformations and doesn't require JVM changes.

The chances are virtually zero regardless. Android implements against a subset of 6 since that's the last freely available release of Java. Building against a newer version of Java seems at this point to be impossible without a huge reconciliation and subsequent licensing deal with Oracle.

Far more likely is some sort of switch to LLVM and something on top of that, IMO, though I find it hard to believe that Dalvik won't continue to be supported indefinitely.

# ¿ Oct 16, 2012 17:12

Doctor w-rw-rw-: Jun 24, 2008

Munkeymon posted:

It's obviously not impossible to compile other languages to Dalvik, so why couldn't they transition to a different official language? Granted, I'm not sure what that would be* and I didn't realize newer Java versions had to be licensed now. Wonder what that does to OS Java (or JVM-dependant) projects.

*it would be hilarious to watch the corporate tears flow if Google bought xamarin and stated giving that toolchain away. E; Not that they ever would, but still

Like Python with its PEPs, Java is extended with JSRs, or Java Specification Requests. These JSRs come with a spec, a reference implementation, and tests for compliance.

These tests in the TCK, or Technology Compatibility Kit, must be passed to certify an implementation as Java� - that is, the trademark must only be used by certified-compatible implementations.

After Java 6, Oracle locked the TCK down. Basically, only Java distributions substantially derived from OpenJDK may be tested with it, and it also puts field of use restrictions specifically banning implementations on mobile devices. What this means is that Android, with its own VM, and residing on mobile devices, can neither use OpenJDK nor test their own VM against the test suite.

Additionally, the Android classpath was derived from Apache Harmony, an alternative, legal, Apache-licensed Java classpath (implementations of the basic stuff like java.lang.String and other underpinnings of the platform). Apache Harmony went defunct after Apache abandoned the project due to the aforementioned controversy spawned over Oracle's refusal to grant a TCK license.

What this means is that in order to update Dalvik with features found in Java 7+, it must reimplement each feature described in the specification without testing it for strict compatibility. This is *if* the license for the JSR allows them to in the first place, and I highly suspect it does not.

Java 7+ couldn't undo the GPL'ing of the codebase or the Java 6 specifications (also open-sourced), but it did shut out third parties that didn't play ball from certifying that they were in fact Java, thus barring them from using the trademark. The only thing allowing Google to claim Android runs Java is the intermediate step where, briefly, the code is in fact Java, or Java bytecode, runnable on Oracle's JVM, before it is transformed into Dalvik bytecode, which is the abstraction past which Google has never claimed they run Java.

Java 7 is not happening on Android ever, barring another huge legal loophole (Dalvik was designed to be a legal loophole, not just a VM, because it's strictly less capable than the JVM) or an OpenJDK or TCK licensing agreement out of nowhere (unlikely given Oracle's severe butthurt).

Xamarin would also be a plausible solution, especially given XobotOS, and the similarity between Java and C#. Unless Google wants to pour money into an agreement with Oracle, which while unlikely, isn't impossible, it's hard to see the Java language staying up to date on Android. Whether or not Google intends to languish at 99% 1.6 compatibility or take an entirely different approach remains to be seen.

Doctor w-rw-rw- fucked around with this message at 22:50 on Oct 16, 2012

# ¿ Oct 16, 2012 22:35

Doctor w-rw-rw-: Jun 24, 2008

kitten smoothie posted:

It took a year and a half but some jackass has posted a paid app of mine to half a dozen of those APK share sites.

Is the license service worth implementing or is that something that these guys have figured out how to work around?

Somewhat convoluted to implement and yes, it has been broken. If the pirates are motivated, they may break it. Welcome to the world of DRM. Sucks on the receiving end.

if it turns out to be a reliable way of determining your pirates' identities then instead of halting the app and cutting them off, you can get tricky with them and quietly log them as pirates. Then if your app deals with data, you can introduce glitches. If you have an in-app support form, you can send along its license status, so you can call the pirates out personally, and ask them to buy the application. Or, just shame them:

# ¿ Oct 17, 2012 10:08

Doctor w-rw-rw-: Jun 24, 2008

kitten smoothie posted:

Yeah, I was reading through the license manager docs later last night and realize it's way too much time for me to implement something that will probably be just as easily broken.

I just need to look on the bright side. It's a $2 mobile radio app I made for a buddy of mine's station, and the more listeners there are, the more he can claim to his advertisers and make his rate card look better.

I have an Admob-enabled free version of the same app out there, and Admob honestly has paid crap for me. So the person who pirates it probably would have otherwise been one of the tons of people using the free version and barely earning me peanuts on it anyway.

Admob is poo poo. YuMe is better, but poorly implemented. Tremor is fantastic.

# ¿ Oct 17, 2012 19:45

Doctor w-rw-rw-: Jun 24, 2008

Karthe posted:

Can you guys point me in the direction of any resources that would help me create a dictionary app? This'll be my first attempt at developing something for Android and I figured I'd go all in and (attempt to) make a Japanese-English dictionary. I know XML parsing is going to be involved, but I have no idea what best practices are with regards to storing and querying information stored in a hundred megabytes of XML. Do I query the XML directly? Do I import it into some kind of SQL engine? I've never had to deal with this much information before.

I'd probably pre-digest it into a sqlite db and include that with the app rather than parse XML, license for said information allowing. Then you can point cursors to it and use all the built-in database stuff.

# ¿ Nov 16, 2012 00:51

Doctor w-rw-rw-: Jun 24, 2008

Geekner posted:

They try to minimize the size of those examples, to make it easier to figure out. It is pretty normal to use anonymous inner classes for little things like OnClickListeners and such. But yea, just follow whatever Java style guide you feel is best for you, you won't run into any real issues.

I shudder every time I see Enterprise� quality code in an android app. Google put a lot of effort into making Dalvik a simple, straightforward Java.

I am somewhat guilty of this, having just discovered IntentServices and (Detachable)ResultReceivers as a substitute for using AsyncTasks to make network calls with a callback-like pattern. It's not awesome, but it's sufficient, and still works when specifying the service to run in its own process.

Live and learn. Can't build something good without building a few horrors along the way, I suppose.

# ¿ Nov 21, 2012 03:42

Doctor w-rw-rw-: Jun 24, 2008

HOLY loving poo poo :frogsiren:

https://github.com/jfeinstein10/SlidingMenu

Compile the example and try it out, or install it from the App Store: https://play.google.com/store/apps/details?id=com.slidingmenu.example

This actually works.
Amazingly well, in fact.
Even on 2.1.

As an Android developer I can't understate just how much this library will improve my quality of life. Dunno if anyone else is as thrilled by the existence of this library as I am.

# ¿ Nov 29, 2012 02:11

Doctor w-rw-rw-: Jun 24, 2008

TheReverend posted:

Anybody going to AnDevConIV in San Francisco next week?

I would if only I weren't considering completely abandoning my career in Android development in a couple of months.

# ¿ Nov 30, 2012 23:36

Doctor w-rw-rw-: Jun 24, 2008

Sab669 posted:

As someone whose been wanting to get into it, may I ask why that is?

Extreme bitterness, :qq:

, and

below.

, you say? Okay, well...this will quickly descend into self-absorbed ranting so stop reading whenever you like. It's spoilered because I don't really want to make this thread discuss it any more than it has to, and I'm perfectly happy if people just skip over this.

Hardware manufacturers lie about what their devices are capable of, each handset maker has their own flavor of bugs to target (Samsung: lovely video players. HTC: theming incompatibilities. Motorola: stupid, difficult to notice bugs with cursors and setting activity orientations). Vanilla Android is nigh unusable, you've got to use the Android Compatibility Library and ActionBarSherlock at a minimum. ViewPagerIndicator, SlidingMenu, RoboGuice, and AQuery are optional, but may be good ideas. More if you want to do animation (NineOldAndroids). The Fragment*PagerAdapters handle fragments in viewpagers really poorly.

Google doesn't dogfood well and it really, really shows. The platform is structured very logically, and if you know what sucks and what doesn't you can do anything, but Android gives you 20 options and it's a challenge to pick the one that sucks the least. Since it's Java, it's easy to refactor, but at the same time you overcommit to structure and it's not really as flexible.

Building a mental model of exactly what is happening at any given point is really loving difficult because the activity lifecycle is awful, and it gets worse when you mix in Fragments. PROTIP: attaching and detaching your fragments doesn't necessarily correspond to onAttach and onDetach.

The entire process of developing for Android is one big slog against a horrible SDK where "working" and "doesn't look awful" on most devices is an astounding success. And what should be the official conference to learn about how to program the drat things has become a device-grubbing frenzy of opportunists. Was I pissed that I woke up an hour before signups opened (they opened at 6AM) and tried for the entire duration of the Google I/O ticket availability (30 minutes) just trying to get a ticket for work, only to have several of my friends sell off their free devices (for hundreds of dollars!) and not even loving attend? HELL loving YES.

I started as a generalist developer and then dove into iOS, which I found pretty enjoyable. Because I was reasonably multitalented - I can do ops, backend, a bit of HTML/CSS and just a little bit of JS - I was put on Android (and during this time, at no point was I even allowed to touch the backend code!). I grew bitter until I left that job, then contracted for a bit, which was quickly put to a stop by the guy I was contracting for screwing me hard (giving me half of what we agreed to and him insisting I was happy with that as far as he knew), followed by a job at a company I like with people I like, except for the fact that I was hired as an iOS developer, then, because we needed an Android app, put on Android again, and my boss essentially refuses to let me grow into other roles now - and to add unintentional insult to injury, multiple new hires are working on projects that I suggested we implement, and which I would be fantastically happy to work on. So instead I'm stuck working on a platform I don't love, and my will to care about the app and its users has finally been exhausted, I've stopped investing my mind into really working out why some bugs happen or how best to approach problems, and I find that awful because I really, really want to care. My enthusiasm as a whole for programming has gradually reduced to the point where despite the fact that I've been programming and aiming to work in Silicon Valley (which is where I work) since I was 5 (that's 19 years), I don't find the idea of leaving it completely unpalatable, though the money's too good and I'm too competent to really ever leave programming for good.

Android is not a platform you want to work on if you value your sanity. In ten years' time - hell, five years' time, even - it will be COBOL: old, hard to grok, and only a few bitter crusties who know the system too well and are too valuable to ever stop will remain. Android's flavor of Java will never be upgraded to Oracle's, period. There simply is no way barring a massive reconciliation between Google and Oracle and a sweetheart deal that Larry Ellison would never offer.

Though I get recruiters pestering me multiple times per week, it's always to become an Android developer somewhere else. Well, compared to my employer, most other companies seem full of poo poo, because well, I do love my company. But I've had it up to HERE with all the bullshit that Android entails and I'm never going to escape it unless I draw a line somewhere and make plans to rebuild my career doing something else.

So if you want to gently caress over your career, try doing Android full-time.
If you want to go nuts over a half-baked framework, try doing Android full-time.
If you want to bang your head against the desk because you just spent three months writing something unusable because a small detail makes it impossible to do something right, try doing Android full-time.
If you want to risk driving yourself into depression because you feel like you're constantly hitting dead-ends and wasting time, try doing Android full-time.

If you don't want to risk any of that, stay the gently caress away!

# ¿ Dec 4, 2012 06:45

Doctor w-rw-rw-: Jun 24, 2008

Oops, my rant mode got engaged. Since this post is about Android problems rather than why Android is a soul-sucking abyss, it's not spoilered:
-----

Oh, and Google totally pushed GoogleTV and made a bunch of people invest in developing apps for it only for it to totally flop. Its saving grace is that it's mostly compatible with Android. Mostly, because, well, it *is* Android, but a couple of things don't work exactly like you'd expect.

I mean, they didn't even have HLS on launch for video streaming for GoogleTV, changed what the ActionBar even was multiple times during development, had UI guidelines that weren't particularly great, told us to fix a bug that Google themselves had no clue how to fix, and their freaking Android Market app, on launch, filtered out ALL applications because it was developed against a newer version of Android than the GoogleTV ran on at the time.

At least they had the good sense to pull the Nexus Q before it launched. A friend (one of those who went for the swag) showed it to me. It basically didn't work. It was clearly trying to be AirPlay and couldn't even do that.

Not to mention, even after release, the Xoom and the Nexus 7, which as first-class devices ostensibly have first-class support for video playback, are prone to just black-screening when playing high-quality HLS streams with encryption. Also, although I should have known better, running two video views on some devices works while it breaks on others. Even on devices which are greater than version 2.3, meaning they use StageFright rather than godawful OpenCore (note: Samsung devices of particular versions will actually lie and say StageFright is enabled and then use OpenCore).

Google's EasyTracker addon to the Google Analytics library is easily the single biggest source of application crashes in my app. Don't use it, just use the analytics library directly.

And it's taken how many years for Google to get its head out of its rear end and finally realize the development process is broken and switch from Ant to Gradle? That their own set of Android library projects is just a workaround for forgetting to account for dependency management in Java, the ecosystem of a billion jars, and that it integrates not at all with them?

Oh, and Andy Rubin firmly believing in the lack of a distinction between a mobile device and tablet devices, thus leaving every developer to decide on the line themselves. Consistency? Who needs that? Got expectations? You're on your own!

So yeah. I could literally find things to rant on for hours.

# ¿ Dec 4, 2012 08:41

Doctor w-rw-rw-: Jun 24, 2008

TheReverend posted:

If it makes you feel better I spend 90 percent of my time making and maintaining a windows mobile 6 app.

*wince* How has the platform aged? Got any history Android can either learn from or doom itself to repeat (depending on your preference)?

# ¿ Dec 4, 2012 11:25

Doctor w-rw-rw-: Jun 24, 2008

^ We should probably update the op sometime soon. Which tutorials have you found the most useful, and for what?

Found a neat library that seems to work well and plays nicely with SlidingMenu: DragSortListView. If you've ever wanted a list of items with drag-to-reorder, today is your lucky day. Its API seems to be sensible, too.

try out the demo on google play.

# ¿ Dec 11, 2012 18:32

Doctor w-rw-rw-: Jun 24, 2008

Glimm posted:

I lazily linked to this post from the OP and added Drag-Sort-ListView to the list of useful libraries.

Neat, thanks. Mind adding the link to SlidingMenu? It's mentioned in the same line as DSLV but not as its own bullet.

# ¿ Dec 12, 2012 00:18

Doctor w-rw-rw-: Jun 24, 2008

Gimbal_Machine posted:

I hear ya. I wouldn't say its career ending and I even enjoy it some days. I've officially been working on android full time for 3 years now.

The constant chorus of 'look at the source code' is a complete and utter joke. The source code is incomprehensible in many spots, using terrible package level linking, hidden and non-accessible methods, and providing non-extensible base implementations. This coupled with fairly sloppy coding standards just leads to serious direction setting issues, which you mention.

Pretty much everything requires special treatment. Device differences, OS level differences, manufacturer differences all add up to serious trouble.

OTOH, I don't think Android development is career ending. We get recruited all the time and the coding practices/debugging/hacking/profiling stuff is transitive to other languages.

I actually like how hard it is most of the time. I don't know that I agree with the sentiment that the SDK works against you. I really like ant, so thats a non-issue for me. Languages are languages. Libraries suck. You make lots of good points. There are just some things you kinda have to act like teflon about (gently caress senseui)

As far as recommended libraries, i've really enjoyed using ORMLite http://ormlite.com/ which, in my opinion, is much more usable then the ContentProvider framework Google proposes.

It's career ending if Android was supposed to be a 1-or-2 month side project that you really didn't want to do in the first place, but did because you were the most qualified at a small company you liked -- then ended up doing for two years, neglecting your other skills and passions, hating yourself the whole time. My situation isn't common I'm sure. It's gotten to the point where I've stopped caring about my work and about programming, even though I've been doing it for 80%+ of my life - and I'm not even 25 yet.

Agreed on the other parts though.

# ¿ Dec 12, 2012 06:43

Doctor w-rw-rw-: Jun 24, 2008

Ranma posted:

If I have a service, and inside this service I start multiple threads, is it possible for these threads to be killed by the OS to free up memory, WITHOUT the Service also getting killed?

If its under enough pressure to kill the threads it'll probably be under enough pressure to kill the service? My preferred pattern for using threads, if you must, is using executor services. Shutdown on stop, start on start. It's a bit more nuanced than that but it worked well. What are you trying to do, exactly?

# ¿ Dec 22, 2012 04:46

Doctor w-rw-rw-: Jun 24, 2008

Ranma posted:

I have http PUT requests that cannot be lost. Every time one is generated, I shove it in a SQLite database and send a broadcast to my request runner service. That starts a thread to run all the pending requests in the database. It does this by loading all the requests with SYNCHRONIZED=0, then setting SYNCHRONIZED=1 for each request. If a request fails, it sets SYNCHRONIZED=0. If it succeeds, SYNCHRONIZED=2. But if the thread were to get killed, SYNCHRONIZED would remain at 1 until the service is killed and restarted, at which point it sets all of the requests with SYNCHRONIZED=1 to SYNCHRONIZED=0.

My first instinct would be to use IntentService, and see how that works for you (but no parallelism). My second reaction would be to use an ExecutorService with a threadpool. I don't think you can have any strong assurance that the service won't be killed, mainly because Android is poo poo and even when I did implement a service that should have been started from app launch and should never have died, it would still show NPEs due to not existing on some platforms.

# ¿ Dec 22, 2012 17:37

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 12:22

Doctor w-rw-rw-: Jun 24, 2008

Geekner posted:

You can run "android update project" from the command line to update the ant build files for that project. You can also import the project into Eclipse and build it using the export function (right click project -> export -> android).

Just make sure they didn't do any weird customization in the build.xml, it'll get replaced when you run the update.

I forget the name of the file, but there is a specific XML filename that will add and override goals specified in build.xml, if memory recalls.

# ¿ Jan 6, 2013 09:14

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > My Code is Fragmented - Android Development Megathread

«‹›3 »