4 ms·

> I'm disappointed to see an ecosystem of re-inventing the same (boilerplate) wheel Do you have some examples ? Nowadays with "modern" Android dev practices,

> I'm disappointed to see an ecosystem of re-inventing the same (boilerplate) wheel Do you have some examples ? Nowadays with "modern" Android dev practices, the amount of boilerplate I write in day to day dev is pretty minimal.

g_p 6y ago
The examples given by Android Annotations spring to mind - http://androidannotations.org/ http://androidannotations.org/ To throw some trivial examples from the top of my head, to just make a button do something when clicked, you need to call setOnClickListener to a new OnClickListener lambda type thing. I just found absolutely every step of the way clunky and unwieldy. The amount of typing and keystrokes required to achieve anything was 5x more than it seemed to need to be, even with auto completions. I just wished for an event driven model like VB6 and old desktop programming, where the focus of the code was on my own logic and functionalities, rather than remembering I have to manually fetch every view by ID because of some arcane reason to do with how Android splits the UI and Java worlds! Maybe my issues are outdated and fixed? Maybe android annotations has come far enough to alleviate my annoyances? I guess the day I can write a pleasant looking Android app that doesn't require me to think about someone else's vision for how my activity should behave in a complex lifecycle of different events, I'll be happy... What happened to sane defaults? Maybe my app (with its activities inheriting from activity) should have sane defaults already in place from the parent class, avoiding my need to even see such horrors, unless I want to?
- on_and_off 6y ago
  oh wow that's one blast from the past ! I remember that project from very long ago (I never used it for various reasons) hmm As far as click goes -> myButton.setOnClickListener { doSomething() } kotlin makes this pretty minimal, I don't really see much we can remove there
  - pjmlp 6y ago
    If Java had proper support, the click example would be quite similar.
    - ptx 6y ago
      Are you saying that Android doesn't have proper Java support? In what way? I thought Java lambdas could be used with SAM interfaces, just like in Kotlin. (Or are you saying that if Java supported Kotlin syntax it would look similar to Kotlin?)
      - pjmlp 6y ago
        Android Java is a Java 8 subset, they are still catching up with Java 8. https://developer.android.com/studio/preview/features#j8-desugar https://developer.android.com/studio/preview/features#j8-des... Jake Warthon was doing contributions to support newer versions, but it remains a lotto what might eventually be supported long term, thus forcing Java library authors to have Android specific versions, or constrain themselves to what all flavours might actually support. As for SAM, yes you are right, but many Android developers only know Android Java and still think Java == 6 || 7.
- ohgodplsno 6y ago
  Please never use androidannotations in a modern Android project. The codegen it does behind the scenes makes your compile times so much longer. It's been less than a month since it finally supported incremental compilation support. In addition, it's a lot of non configurable magic that will bite you if you ever need to do something a bit funky with different resources. If you use kotlin, you can make use of synthethics which will automatically provide you with variables that bypass the need of calling `findViewById<T>`, including proper type inference. A slight step further, ViewBindings actually also give you type safety and null safety, depending on your layout. Then it simply becomes a matter of `binding.buttonThatIsNotHereOnLayout2?.setOnClickListener(this::onButtonClickedDoThing)`. Even if using Java, you can use the shorthand lambdas to do button.setOnClickListener((v) -> this.onButtonClicked()). Much of the rest that is shown are matters of dependency injection, or are fixed with newer updates to the Android SDK. Fragments can have their layouts specified directly in their constructor, AsyncTasks have been deprecated over and over again, etc. AndroidAnnotations was alright in 2015-2016, where the Android API was truly dreadful. It still is, but most of the truly awful things are gone.
  - g_p 6y ago
    Thanks - sounds like the world of Android development has evolved a lot since I last looked at it. There's a lot of talk around Kotlin, so I guess it's time to look at that transition and what happened there. It sounds promising if most of the bad and horrifying things are gone since the days of 2015/2016 when these tools helped!
    - ohgodplsno 6y ago
      Don't get me wrong, there's still plenty of crap. Google dug themselves in a deep hole with their god activities and insane fragment lifecycle. But if anything... The fragment lifecycle is about the worst there is now. The AndroidX libraries have done it a lot of good.

g_p 6y ago

The examples given by Android Annotations spring to mind - http://androidannotations.org/ http://androidannotations.org/ To throw some trivial examples from the top of my head, to just make a button do something when clicked, you need to call setOnClickListener to a new OnClickListener lambda type thing. I just found absolutely every step of the way clunky and unwieldy. The amount of typing and keystrokes required to achieve anything was 5x more than it seemed to need to be, even with auto completions. I just wished for an event driven model like VB6 and old desktop programming, where the focus of the code was on my own logic and functionalities, rather than remembering I have to manually fetch every view by ID because of some arcane reason to do with how Android splits the UI and Java worlds! Maybe my issues are outdated and fixed? Maybe android annotations has come far enough to alleviate my annoyances? I guess the day I can write a pleasant looking Android app that doesn't require me to think about someone else's vision for how my activity should behave in a complex lifecycle of different events, I'll be happy... What happened to sane defaults? Maybe my app (with its activities inheriting from activity) should have sane defaults already in place from the parent class, avoiding my need to even see such horrors, unless I want to?

on_and_off 6y ago
oh wow that's one blast from the past ! I remember that project from very long ago (I never used it for various reasons) hmm As far as click goes -> myButton.setOnClickListener { doSomething() } kotlin makes this pretty minimal, I don't really see much we can remove there
- pjmlp 6y ago
  If Java had proper support, the click example would be quite similar.
  - ptx 6y ago
    Are you saying that Android doesn't have proper Java support? In what way? I thought Java lambdas could be used with SAM interfaces, just like in Kotlin. (Or are you saying that if Java supported Kotlin syntax it would look similar to Kotlin?)
    - pjmlp 6y ago
      Android Java is a Java 8 subset, they are still catching up with Java 8. https://developer.android.com/studio/preview/features#j8-desugar https://developer.android.com/studio/preview/features#j8-des... Jake Warthon was doing contributions to support newer versions, but it remains a lotto what might eventually be supported long term, thus forcing Java library authors to have Android specific versions, or constrain themselves to what all flavours might actually support. As for SAM, yes you are right, but many Android developers only know Android Java and still think Java == 6 || 7.
ohgodplsno 6y ago
Please never use androidannotations in a modern Android project. The codegen it does behind the scenes makes your compile times so much longer. It's been less than a month since it finally supported incremental compilation support. In addition, it's a lot of non configurable magic that will bite you if you ever need to do something a bit funky with different resources. If you use kotlin, you can make use of synthethics which will automatically provide you with variables that bypass the need of calling `findViewById<T>`, including proper type inference. A slight step further, ViewBindings actually also give you type safety and null safety, depending on your layout. Then it simply becomes a matter of `binding.buttonThatIsNotHereOnLayout2?.setOnClickListener(this::onButtonClickedDoThing)`. Even if using Java, you can use the shorthand lambdas to do button.setOnClickListener((v) -> this.onButtonClicked()). Much of the rest that is shown are matters of dependency injection, or are fixed with newer updates to the Android SDK. Fragments can have their layouts specified directly in their constructor, AsyncTasks have been deprecated over and over again, etc. AndroidAnnotations was alright in 2015-2016, where the Android API was truly dreadful. It still is, but most of the truly awful things are gone.
- g_p 6y ago
  Thanks - sounds like the world of Android development has evolved a lot since I last looked at it. There's a lot of talk around Kotlin, so I guess it's time to look at that transition and what happened there. It sounds promising if most of the bad and horrifying things are gone since the days of 2015/2016 when these tools helped!
  - ohgodplsno 6y ago
    Don't get me wrong, there's still plenty of crap. Google dug themselves in a deep hole with their god activities and insane fragment lifecycle. But if anything... The fragment lifecycle is about the worst there is now. The AndroidX libraries have done it a lot of good.