4 ms·

I have to admit I often roll my eyes at the state of mobile development, especially on Android. I worked on a few Android apps in 2009-2012 when a "best practi

• ohgodplsno 6y ago
  >Like I was interviewing a guy for an Android role, and he was walking me through a pet project of his which consisted of literally one list view which updated it's contents to filter results out of an SQLite database as you type into a text field, and the project had literally dozens of files. It just made me sad. That's most likely overengineering. The only things you need for this are: - An Activity - Eventually, a Fragment, but you can do your work in the activity directly - A database, optionally in another file to abstract out direct queries, but it can simply be direct SupportSQLite queries. Just, not on the main thread. - A viewmodel if you don't want to hate yourself and write logic in your Activity, making it basically untestable. - A layout file for your activity/fragment. - A layout file for your recyclerview list element That's 5 files. 6 if you include build.gradle, 7 with AndroidManifest.xml This can all be written in under 500 total lines. Library wise, all you need for that is androidx and recyclerview.
  • arexxbifs 6y ago
    I honestly can't tell if this is a joke? 0.5 KLOC. Seven files. That's not over-engineered?
    • deleted 6y ago
      [deleted]
    • ohgodplsno 6y ago
      A lot of that is due some Android APIs being insane. Amongst all of those, the RecyclerView adapter will be over a hundred, because it is a stupidly verbose API. Layouts are XML, so, yeah, stupidly large too. Those two contribute to a lot of those lines. Not so much overengineered as lol-google-apis engineered. ViewModels are also due to the batshit insane android lifecycle, where you can easily be bitten in the ass. All of those are not for fun. They're because the Android APIs are terribly crap, or because you're not allowed to do certain things on the main thread (like, say, database queries) After that, you can very well put your activity/fragment/database logic in the same file, if you know you're never going to maintain it.
      • Larrikin 6y ago
        No matter how many times I write a recyclerview, which is usually atleast one for any new screen, it never stops being the worst part of Android dev for me.
      • m_fayer 6y ago
        I used to say it a lot. It's been a long time now, but heck for old time's sake: how I miss Windows Phone.
      • noema 6y ago
        "Best practice Android development" is soon to phase out XML (for the most part) with Jetpack Compose. Working with two way data binding in XML seemed like a good idea, until you had to debug it.
        • ohgodplsno 6y ago
  • ShamelessC 6y ago
    I thought 12 was hyperbole for 3 or 4. All you've done is shown that the default encourages 7 files. Going from that to 12 with some questionably early refactoring sounds quite possible.
    • ohgodplsno 6y ago
      The quoted post says "dozens", plural. I can easily see new developers overengineering something that big.
  • catalogia 6y ago
    > one list view which updated it's contents to filter results out of an SQLite database as you type into a text field In racket/gui this could be maybe 100 clean lines of code in one file.
    • ohgodplsno 6y ago
      Probably, yes. Hower, does Racket handle configuration changes (orientation, language, etc.), recycling list items to lower memory usage, arbitrary layouts for lists (and not just a single line of text) with diffs calculated between renders, and more ? Android is complex, yes. Sometimes for no reason (hello God Activities). But sometimes, it has good reasons to do so. I actually wrote one, with the bare minimum. HNActivity.kt is 81 lines and handles updating the list, querying import android.database.sqlite.SQLiteDatabase import android.os.Bundle import android.view.LayoutInflater import android.view.View import android.view.ViewGroup import android.widget.EditText import android.widget.TextView import androidx.appcompat.app.AppCompatActivity import androidx.core.widget.addTextChangedListener import androidx.recyclerview.widget.DiffUtil import androidx.recyclerview.widget.LinearLayoutManager import androidx.recyclerview.widget.RecyclerView import kotlin.concurrent.thread class ListItemVH(val view: TextView) : RecyclerView.ViewHolder(view) class HNActivity : AppCompatActivity() { private lateinit var recycler: RecyclerView private val adapter = object: RecyclerView.Adapter<ListItemVH>() { private var _items = listOf<String>() fun setItems(newItems: List<String>) { DiffUtil.calculateDiff(object: DiffUtil.Callback() { override fun getOldListSize(): Int = _items.size override fun getNewListSize(): Int = newItems.size override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int) = _items[oldItemPosition] == newItems[newItemPosition] override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int) = _items[oldItemPosition] == newItems[newItemPosition] }, true) _items = newItems } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ListItemVH { val v = TextView(parent.context) return ListItemVH(v) } override fun getItemCount(): Int = _items.size override fun onBindViewHolder(holder: ListItemVH, position: Int) { holder.view.text = _items[position] } } private var search: String? = null override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_scrolling) recycler = findViewById<RecyclerView>(R.id.fab) recycler.adapter = adapter recycler.layoutManager = LinearLayoutManager(this, LinearLayoutManager.VERTICAL, false) findViewById<EditText>(R.id.toolbar).addTextChangedListener { search = it?.toString()?.takeIf { str -> str != null } } } private fun performSearch() { thread { val db = SQLiteDatabase.openOrCreateDatabase("items.sqlite", null) val query = when (search) { null -> "SELECT text FROM table" else -> "SELECT text FROM table WHERE text = ?%" } val args = listOfNotNull(search).toTypedArray() val res = db.rawQuery(query, args) val text = mutableListOf<String>() while (!res.isAfterLast) { text += res.getString(0) } adapter.setItems(text) res.close() db.close() } } override fun onResume() { super.onResume() performSearch() } } Add in another 30 lines for the Activity layout, and you've got your thing. You've also got every single developer you'll work with hating you, and you'll hate maintaining this code. Just in those few lines, so much can go wrong (thread gets started and activity gets backgrounded? Oops, you crashed.)
• 0xcde4c3db 6y ago
  With Android, part of the problem is that a solid ~80% of the "how to" information out there (and a distressingly high percentage of the official documentation) tells you to use things that were either deprecated years ago or are about to be deprecated in the next version of Android. Since the framework has gone through multiple iterations of this dance, you basically need to learn the whole history of any API you're using before you can decide how some part of your app is going to work. Or you can pull in a library that seems to be popular and maintained and solves the problem that you have.
  • karatestomp 6y ago
    That, and there's a lot of "folk knowledge" around how to do things that the docs ignore. The cleanest and most efficient (or even just non-broken) way to do even basic shit is often to ignore how the docs say to do it and use some library. The whole platform feels badly neglected, like the only time anyone gives it serious attention is to throw some half-implemented shiny feature on top so they can announce it at an event, then never touch it again.
  • mook 6y ago
    I think a large part is that the first-party documentation is pretty bad. My only exposure to the Android toolchain has been writing my own toy application, and it's just sad that the docs are terrible. Things like "this thing that used to be in the platform API had been replaced by that thing in appcomapt" → "nope it's in androidx now" → "this replaces that thing in the platform API, go read the docs for that instead". Essentially, you _have_ to read deprecated documentation to do anything… At least it's better than some other ecosystems, where it's "this thing is deprecated now. Nothing replaces it and you can't do similar functionality any other way, it's just deprecated." Or maybe I just haven't gotten to that part yet.