A week ago, I published AndroidDeviceNames, a library transforming device models into something people can understand, e.g. SM-N910W8 to Samsung Galaxy Note 4. Some of you did not like the implementation. Here’s the reasoning behind it.

why not just use switch statement over strings and emit Java 7 bytecode? Dexer will allow it and you'll get a bytecode implementation of a hashtable.

Hi guys, author here. I’ll be around, so feel free to ask me any questions you may have.

Here’s the link to the library and comments from last week.

Let’s be a bit more more constructive this time - if you say A is better than B, or use C instead of D, or this is shit because of E, please provide some context or references backing your claim. Also, please don’t do code reviews/pull requests on auto-generated code. :)

Factors to consider:

• memory consumption
• execution time
• code maintainability

Given this class is loaded once, and executed once, I'm not sure memory or execution time were really problems with the .properties implementation. How much did that 60k of ram really hurt? And notably: the .properties implementation didn't require a python build script.

You may have committed the sin of premature optimization

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

And after all that, you landed at an O(n) implementation. If you're going to optimize the snot out of this just for fun, don't stop there! Maybe get fancy, and store a compressed trie data structure in your class?

In conclusion, you've either gone too far, or not far enough ;)

I suggest using enums.

For an immutable list lookup, with pre-processing available, here's another method you can use:

• write a custom hash function which converts the model name into an integer n where 0 <= n < 400 + x, the hash function has zero collisions, and x is minimized. This function is left as an exercise for the reader.
• create a flat file which contains all the name mappings. This can either have an index thus allowing variable length strings and minimizing the file size, or no index which allows slightly faster lookup but at a larger file size. This file is a very simple database-esque file.
• the lookup method then hashes the model name, producing an integer which is byte offset into the file, allowing random access.

This is very fast, and has zero memory overhead, and a small code footprint.

Thanks a lot for posting this. This is a great write-up and it's clear you put a lot of thought into how and why you structured your project the way you did.

Pay no mind to the peanut gallery. Everyone can always find issues with code they themsleves didn't write within the last 24 hours, simply because it's "not how they would've done it".

And thanks for the library!

How about keep all in array, sorted, then use binary search? O(log n) Am I right or I missed something? It takes memory but it will search faster thank picking first letter.

Really cool! I always appreciate case studies like this, this was the type of stuff in college that I was really passionate about. Great write-up with solid empirical reasoning behind it.

If you want to do this pragmatically, why not do it on a per manufacturer basis? The advantaged being you don't have things hard coded and you should be able to decode future models with some accuracy.

Pseudo-code (No language like this exists):

Public Structure DeviceInfo {
	Public sManufacturer as String = "Samsung"
	Public sLine as String = "Galaxy"
	Public sModel as String = "S"
	Public sSubModel as String = "Active"
	Public sEdition as String ="IV"
	Public nEdition as Integer = 4
}

Public Static Function getDeviceInfo() as DeviceInfo {		
	dim oDeviceInfo as new DeviceInfo
	oDeviceInfo.sManufacturer = android.os.Build.MANUFACTURER
	Switch(oDeviceInfo.sManufacturer){	
		Case: "SAMSUNG"
			 loadSamsungDevice(oDeviceInfo)
		Case: ...
	}
}

Private Static Subroutine loadSamsungDevice(ByReference *oDeviceInfo as DeviceInfo) {		
	if(android.os.Build.MODEL.startsWith("GT-"){
		oDeviceInfo.sLine="Galaxy"		
		if(android.os.Build.MODEL.substringAfter("GT-").startsWith("I")) {
				etc....
		}
	}	
}

Then the app consuming the library can put it all together.

As an aside, a few months ago I dumped the list of devices from the Google Play Dev Console so I could create a lookup for my application. Let me know if you want the dump (it's something like 2400 devices in total).

[deleted]