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 »

zeekner: Jul 14, 2007

I hate to say it, but you are probably in for a world of pain.

Newf posted:

Aiming for a launch date in July, with a 'pilot' deliverable in June. How much time / red tape should one expect for submitting an app to the Play store and the App store?

No red tape for play store, 3-7 day reviews for app store.

Newf posted:

Video display is intended to be in-app. Is there a reason the video files themselves can't just be part of the app install? Then they could play locally. We're talking about 12-15 videos in the range of 45-60 seconds.

An app over 50mb is possible, but harder to recommend. If streaming is an option, I would look into that before you settle for inflating the download size. Local files are a lot easier, though.

Newf posted:

I've done 'hello world' on android, and less than that on iOS.

The app will be free.

Goal is to have it presentable from hand-helds up to tablets.

Going from a fresh newbie to a presentable project is a long and painful process. good luck

Newf posted:

I'm really at a loss for figuring out any estimates. I don't mind making a low wage on the project (I need work, and I need ~*experience*~), but I don't want to give a quote that ends up paying me two bucks per hour.

If you are quoting a flat fee and you have no idea what it will take to accomplish it, you will end up well under minimum wage. Try to negotiate hourly billing, even if you have to quote a rather low rate. It doesn't sound like you are in that great of a position to begin with.

# ¿ Apr 7, 2014 19:34

Adbot: ADBOT LOVES YOU

# ¿ May 13, 2024 13:48

zeekner: Jul 14, 2007

Newf posted:

... the character building kind of pain?

Maybe, but painful nonetheless.

You really need to be careful committing to two completely different platforms, especially if you have little experience in either. ObjC is a reasonably modern C, but it can be pretty jarring coming from a java/c# background. Android uses pretty modern Java as well, in that you aren't hamstrung by a lot of the java 1.4 era stuff you see in other Java-based platforms. You'll probably have a much easier time with the Android app, but don't discount the fact you'll still need to learn quite a lot to get to a finished product. That price estimate might work for just Android, albeit still low, but doing both platforms for that price is really questionable.

Loading videos in the background as they go around sounds like a good compromise. If this is intended for a specific museum, then they can provide wifi to make this easier for users. It's a shame that downloads on cellular are still quite painful even in TYOOL2014.

# ¿ Apr 7, 2014 22:17

zeekner: Jul 14, 2007

Just a heads up: Google IO registration is now open. Signups are open till the 18th, and it's a random drawing instead of the first-come system they had before.

# ¿ Apr 16, 2014 01:09

zeekner: Jul 14, 2007

Rejection emails are going out, so if you haven't seen anything yet you're probably SOL. This is the third year in a row I haven't been able to get a ticket.

# ¿ Apr 22, 2014 00:45

zeekner: Jul 14, 2007

Karthe posted:

While we're talking about Java stuff, can you guys help me understand the difference between

I've seen some code examples that use the this. nomenclature while others use the mTitle technique. Is there a benefit to one over the other?

'this' is just an explicit reference to the member variable, where 'mTitle' is just an implicit reference. The 'mVariable' pattern is just a variation of the application hungarian naming scheme, Google tends to follow it within their own code.

One benefit of that naming scheme is that you don't have collisions that would otherwise require 'this'.

# ¿ Apr 28, 2014 06:01

zeekner: Jul 14, 2007

Karthe posted:

Ah, thanks for confirming my suspicions.

Somewhat related, is there a reason why an 'm' is used as the prefix when naming class variables like 'mVariable'? Based on a quick perusal of Wikipedia's article on Hungarian notation the prefix can denote something about the variable. However, throughout most of the tutorials and open source code I've read, the 'm' prefix is near constant and gives no indication of the type of information stored in the variable.

'm' is for member variables, 'a' for argument variables, and sometimes 's' for static variables. There might be more but I can't think of them offhand. There's a distinction between system hungarian with type-based prefixes like i, l, s and app-hungarian where the prefix defines the functionality of that variable. Since Java IDEs display variable types and alert common type-based errors system hungarian is kinda useless.

# ¿ Apr 28, 2014 06:31

zeekner: Jul 14, 2007

Even with proguard, hardcoded strings are pretty vulnerable. All you need to grab strings is an APK depacker and JD-GUI. The variable names will be a little hard to follow, but anyone can figure it out pretty quick.

This kind of thing is true of pretty much any language, stripping strings from C executables, iphone apps, or anything else is pretty easy. Whatever you do, do not include hard-coded passwords, and try to design your app to avoid including anything else sensitive.

# ¿ May 1, 2014 00:39

zeekner: Jul 14, 2007

Evil_Greven posted:

In that example, yeah - it's just a line of text for the Quake summary; I don't need a custom implementation for that. What you're doing is more advanced than that - but that's beside the point.

You're going about getting the list reference the wrong way, or at least atypically.

As far as I'm aware the typical use is:
1) you need to make your activity extend ListActivity rather than Activity; I missed this on your code before.
2) you are limited to one list, called (as previously) "@android:id/list" in the layout XML.
3) you can then use setListAdapter(adapter); to... yeah.

Try changing just these bits of your activity first, rather than your custom adapter.

There's little reason to extend ListActivity, all it does is grab a reference to the listview and provide helpers for adapter functions. Everything it does can be replicated with a simple findViewById and setting the adapter directly.

ListView itself is pretty simple, and ListActivity only automates the easiest part. The real annoying complexity is in the adapter, and doubly so if you want multiple item types and ViewHolders for more efficient recycling. I ended up creating a custom adapter that handled most of that annoying stuff automatically, but it still requires a little work defining item layouts and functionality.

# ¿ May 14, 2014 22:56

zeekner: Jul 14, 2007

If you are using gradle, just use your release key to sign the debug build. Then you'll never get the inconsistent signing error.

code:

    buildTypes {

        debug {
            runProguard false
            signingConfig signingConfigs.release
        }
     }

Otherwise, you can copy the debug.keystore from one computer to another. It's usually in ~/.android/.

# ¿ May 15, 2014 18:30

zeekner: Jul 14, 2007

Literally Elvis posted:

So this thing is going on tomorrow, and I'm going back and forth on going. On the one hand, I'm certain I'd learn a lot, but on the other hand, it looks like they're expecting people good enough to create things quickly, and I'm nowhere near that adept at this stuff. Also, I have no loving clue what sort of functionality I'd like a watch or other wearable to have beyond just telling time, so even if i were knowledgeable enough to make something quickly, I wouldn't know what.

My gut tells me to just go, and worst comes to worst, not participate as much as maybe the organizers would like, but I wanted to see if people who are maybe familiar with these sort of events would advise against that or not.

They say you can collaborate with others, just go and at worst you can just jump in with someone else. These things aren't high pressure.

# ¿ Jun 11, 2014 18:35

zeekner: Jul 14, 2007

Karthe posted:

Are there any good resources on designing functionality that let users toggle between a light theme and a dark theme? I understand the basics of switching between two themes, but I'm stumped on how to change out the color palettes and icons that are loaded for each theme. Right now my app uses a Theme.Holo.Light-based theme, and so the ActionBar icons and Navigation Drawer use icons and colors themes that account for the predominantly off-white appearance. However, when I set the app theme's parent to Theme.Holo, the ActionBar icons are hard to see and the Navigation Drawer is still white (because of the @color I set it to).

Do themes support something like refs.xml does, in that you can specify different drawables or layouts for a particular value (i.e. for sw600dp devices, @layout/activity_layout in Activity.java instead uses @layout/activity_layout_two_columns)? If not, what can I do so that @color/nav_drawer_bgcolor or @drawable/ac_icon returns one color or icon for one theme, and a different color or icon for another?

Are you specifying attribute values?

Example:
Make an attrs.xml in your values folder, then add something like this:

code:

    <attr name="primaryBackground" format="color|reference"/>
    <attr name="listBackground" format="color|reference"/>
    <attr name="footerBackground" format="color|reference"/>

Then, in each theme's <style>, you can specify colors like this:

code:

	//by value
        <item name="primaryBackground">#000000</item>
        <item name="listBackground">#3E4147</item>
	//or by reference
        <item name="footerBackground">@color/footer_light</item>

Then reference those attributes in xml via:

code:

    android:background="?footerBackground"

Grabbing those values at runtime is a little more annoying, I use something like this:

code:

    public static int getThemeColor(Context context, int colorAttr, int fallbackColor){
        TypedValue val = new TypedValue();
        if(context.getTheme().resolveAttribute(colorAttr, val, true)){
            return val.data;
        }
        return fallbackColor;
    };

Be sure to read and fully understand the resolveAttribute function, how you use it will vary based on the type of attribute you are resolving.

# ¿ Jul 16, 2014 18:15

zeekner: Jul 14, 2007

Tunga posted:

This was helpful, thanks. But now I'm confused about how separators work.

I basically have three lists that I was to display one after another with a small "header" at the top of each one.

Would be easier to just add three ListViews to my layout?

Three listviews wouldn't let you scroll between them.

I haven't worked with the new RecyclerView stuff, but the way I did what you are trying to do is with multiple item types in the same listview. Adapters are actually pretty flexible, but there are a ton of quirks you have to watch out for. I wrote a Adapter/Item library that let me mix multiple different row types and also group them at will. It's how I do section/page dividers in something.apk.

I need to write a few pages of documentation to explain everything it does, but hopefully a brief explanation will help for now:

I have a FastAdapter in FastLibrary, it handles multiple item types, onclick events, ViewHolders, and a bunch of workarounds for silly limitations in Android's ListView.
Basic FastAdapter implementation or the Sectioned Adapter that just allows me to group items together. (Ignore everything outside the list section of FastLibrary, it's all terrible util library bullshit.)

The list items are a subclass of BaseFastItem which implements a bunch of helper stuff and handles ViewHolder creation, view updating, ids, ect. A basic example in Something is the forum Divider which does nothing but show some text.

To use the FastAdapter, just create it and plug it into the listview:

code:

//maxTypeCount is the number of unique view types you will use,
//count the number of different R.layout.X types you will use, you can set it higher than you will actually use.
//this is required because of dumb limitations in ListView recycling management.
adapter = new FastAdapter(yourFragment, maxTypeCount);

listView = (ListView) frag.findViewById(R.id.listview);
listView.setAdapter(adapter);

//(optional) enables onClick callback in your BaseFastItem subclass
listView.setOnItemClickListener(adapter);

Then just create a bunch of list items, which implement BaseFastItem, then insert them into the adapter.

adapter.addItems(yourListItems);
or
sectionAdapter.addItems(groupNumber, yourListItems);

Now having written all of this, I have a big disclaimer: I'm not going to support this library nor do any future work on it, and it's not documented because I am terrible. It works great for what I needed to do, and digging through it should help you understand exactly what ListView is capable of. The new RecyclerView stuff would be a great starting point for a rewrite of this library, but I'm not doing Android development right now so that's probably not going to happen. Hopefully someone will take the new RecyclerView stuff and writes a nice wrapper library for it.

# ¿ Nov 11, 2014 18:22

zeekner: Jul 14, 2007

hooah posted:

There's a nested async task in the fragment that's supposed to be doing that in onOptionsItemSelected:
Java code:
        FetchWeatherTask task = new FetchWeatherTask();
        task.doInBackground();
}

There's a problem, calling doInBackground() will actually do the work in the UI thread. You need to call execute(), which will call the doInBackground method in a secondary thread.

# ¿ Dec 17, 2014 22:45

zeekner: Jul 14, 2007

hooah posted:

Well it would've been nice if they'd loving mentioned that anywhere
Why would telling an async task to do in the background not ...do it in the background??

The doInBackground method is the thing that's being overloaded when you define the task. It's a real poor choice of name, and they probably would have been better off making that function protected/private to hide it. Google is bad at naming/designing/implementing things.

# ¿ Dec 17, 2014 23:06

zeekner: Jul 14, 2007

hooah posted:

I'm a little further on, and now being confounded by JSONObject and JSONArray. I have a JSON string that's the weather data from openweathermap.org. I'm trying to parse the thing to get the max temperature from a given day (day is an int). I read the class overview for both of these classes, and then skimmed through the methods. Here's my code attempt so far:
Java code:
public static double getMaxTemperatureForDay(String weatherJsonStr, int dayIndex)
		throws JSONException {
		JSONObject forecast = new JSONObject(weatherJsonStr);
        JSONArray days = forecast.getJSONArray("list");
        JSONObject day = days.get(dayIndex);
        JSONObject temps = day.get("temp");
        return temps.get("max");
	}
I'm using the Udacity IDE because I'm lazy, and it's giving me a few errors about incompatible types. The first is on the open paren in JSONObject day = days.get(dayIndex);. The message says that a JSONObject is required, but it found an Object. I don't understand why it's looking for a JSONObject, when the documentation says that the .get method of JSONArray takes an int.

The JSONObject/JSONArray get() methods return the item you want, but since Java is type-erasing it's a generic Object and you'll have to cast it. The way better thing to do is call days.getJSONObject() since that will do the cast internally. This applies to every type in the JSONObject/Array, you have getInt/getFloat/getString/ect.

Also, give Android Studio a shot when you have a chance, it's based on the really nice IntelliJ IDE and is pretty well integrated now.

zeekner fucked around with this message at 03:32 on Dec 18, 2014

# ¿ Dec 18, 2014 03:29

zeekner: Jul 14, 2007

speng31b posted:

Just remember, it could always be worse. I have a coworker who reached the dex limit for an app through included libraries and had to go into the bowels of ProGuard for stripping third-party JARs just to get the count low enough to even compile the app.

I've had that happen as well. Avoid Guava if you can, it'll take 16k out of your 65k hard limit.

# ¿ Dec 18, 2014 22:08

zeekner: Jul 14, 2007

hooah posted:

Oh, ok, that's good to know! I know this course expects a fair amount of Java knowledge, but that particular convention wasn't explained at all.

It's an android-specific feature. The resource system lets you place assets that are specialized by device/language/screen-size/ect. The file name of the XML doesn't matter at all, just the type named in the xml itself (the <string> or <array>). The folder it's in determines whether it's used, it's a pretty cool thing that makes a lot of stuff possible. This page explains how the folder structure works, it was probably one of my most referenced pages.

# ¿ Dec 21, 2014 21:10

Adbot: ADBOT LOVES YOU

# ¿ May 13, 2024 13:48

zeekner: Jul 14, 2007

hooah posted:

That does look to be a good resource. Any ideas on my ShareActionProvider compatibility problem?

Ah, didn't see that post. There are two ShareActionProviders, the compat version and the native version for v14+. This applies to most things in the compat library.

Since you are using the compat version, you'll need to make sure you never import the native version. So check your import statements at the top of your file, if ShareActionProvider doesn't have 'support.v7' in the path you'll need to change it.

# ¿ Dec 21, 2014 21:20

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

«‹›3 »