4 ms·

EasyMVP – Android library with annotation processing and bytecode weaving

58 points by joblack33 10y ago

StavrosK 10y ago
Can someone explain what these are? I'm not familiar with Android code.
- BoorishBears 10y ago
  The Android ecosystem is a few decades behind the rest of the development world for design patterns because, to frame it in web technology, every time you resize your window the entire browser restarts and its up to your page to restore its state (Activity/Fragment = Page) People were so busy fighting that mess in the early days they ended up writing a lot of shitty code. Then Android has reached where programming was after Smalltalk came out, about a year ago when MVP became "that exciting new way to write less shitty code" No one really knew what MVP was but they had to have it. Then someone stumbled upon Uncle Bob and everyone needed to write "Clean code" Google threw a wrench in things by releasing its data binding library which is MVVM so now there's the holy wars over that on the horizon. And everyone is doing MVVM bindings the way everyone else figured out was wrong in the mid 2000s (using your bindings to do business logic) so it looks like MVP is pulling ahead before the war even starts. So this library is for MVP that works around the whole "reopen the browser" issue because your presenters get killed when the browser restarts.
  - StavrosK 10y ago
    Wow, great explanation, thank you. I thought mobile programming was at the cutting edge, given how much code and focus there is on mobile apps. I'm sad to hear it's exactly the opposite. I would have imagined mobile devs/languages would have nailed asynchronous programming by now, since mobile apps are basically one huge jumble of asynchronous events and processes.
    - myko 10y ago
      > I thought mobile programming was at the cutting edge It's a lot better thought out and organized within the iOS ecosystem. Android arguably lets you do more interesting things feature-wise, but the SDK is a mess.
    - crla 10y ago
      I don't believe it is as bad as BoorishBears says. Yes, configuration changes cause a tear down and recreation of your view/controller layers, but there are several patterns to deal with this cleanly (view controllers whose lifecycle spans multiple instance of a view is one of the more common, with the view instances detaching/attaching as they come and go). If you use a Flux like pattern for handling application data state you don't even necessarily have to do that since your views are just observing data stores whose lifetime outlives the views anyway. As for asynchronous handling, there are quite a few popular libraries that are very powerful and make it easy to compose multiple asynchronous operations, update views on changes, etc - RxJava for instance has been pretty popular for the last couple of years and is very powerful, but has a steep learning curve. There are others such as Agera (from Google itself), as well as simpler async libraries like Bolts (similar to .Net task futures). The Android SDK itself does not contain much in the way to help with any of this though (I would avoid pretty much any of the async classes that come with the SDK such as Loaders and AsyncTask) - so you do have to research and learn about third party libraries to get to a state where you can write clean and concise code.
      - BoorishBears 10y ago
        Don't get me wrong, I don't mean to imply writing clean apps is impossible but I believe it's a fair assessment of the "state of the Union" for development. Even your comment kind of alludes to the mess: Yeah there's RxJava but it doesn't inherently solve the rotation issue because your Observables so you still need to persist the information needed to recreate them. And any long running tasks need a separate solution because tearing down the Observable will reset the operation Googles app development team made Agera which was widely panned as an inferior NIH RxJava Having your view's controller persist also requires custom logic because only your application will persist through configuration changes and even then the process can still get killed leaving you with nothing but data stored to disk via Parcelables or your own custom solution. Android Devs solved asynchronous operations, the problem is keeping those operations going after a configuration change. If the operations reference the view you'll get NPE when the view is destroyed while a job finishes, and if your view references the operation you need to lay down infrastructure to let your asynchronous operations exist completely separate of the view and be able to cache their results for when the view comes back. It's not impossible, everyone does it somehow, but it's created a lot of divergent theories on how it can be done
  - vvanders 10y ago
    The databinding stuff seemed pretty half-baked to me last time I looked at it. Completely agree that Android is way behind the times with respect to common ui patterns.
  - ex3ndr 10y ago
    > every time you resize your window the entire browser restarts and its up to your page to restore its state Wrong, it can be and often is disabled and windows are just resized without recreating of activities.
    - BoorishBears 10y ago
      Disabling configuration changes is a naive hack (half the people who do it don't even disable every configuration so their apps break on something as simple as plugging in a keyboard with USB Otg or more commonly, tablets). You're still supposed to handle all the configuration changes you disable yourself, and people rarely do. Disabling configuration changes is really for stuff like games where realistically the normal configuration change handling doesn't make sense and proper handling is as simple as resizing your surface or something. And the window thing was part of the browser analogy, not the Android one, but ironically resizing an Android window can force an app to switch layouts causing a configuration change. Windows actually add even more complexity because now apps have to differentiate (to keep the analogy going) between when the user closes the browser and when the user clicks away from the browser (nuances with how the window features interact with stop vs pause which affect stuff like video playback apps)
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]

58 points by joblack33 10y ago

StavrosK 10y ago

Can someone explain what these are? I'm not familiar with Android code.

BoorishBears 10y ago
The Android ecosystem is a few decades behind the rest of the development world for design patterns because, to frame it in web technology, every time you resize your window the entire browser restarts and its up to your page to restore its state (Activity/Fragment = Page) People were so busy fighting that mess in the early days they ended up writing a lot of shitty code. Then Android has reached where programming was after Smalltalk came out, about a year ago when MVP became "that exciting new way to write less shitty code" No one really knew what MVP was but they had to have it. Then someone stumbled upon Uncle Bob and everyone needed to write "Clean code" Google threw a wrench in things by releasing its data binding library which is MVVM so now there's the holy wars over that on the horizon. And everyone is doing MVVM bindings the way everyone else figured out was wrong in the mid 2000s (using your bindings to do business logic) so it looks like MVP is pulling ahead before the war even starts. So this library is for MVP that works around the whole "reopen the browser" issue because your presenters get killed when the browser restarts.
- StavrosK 10y ago
  Wow, great explanation, thank you. I thought mobile programming was at the cutting edge, given how much code and focus there is on mobile apps. I'm sad to hear it's exactly the opposite. I would have imagined mobile devs/languages would have nailed asynchronous programming by now, since mobile apps are basically one huge jumble of asynchronous events and processes.
  - myko 10y ago
    > I thought mobile programming was at the cutting edge It's a lot better thought out and organized within the iOS ecosystem. Android arguably lets you do more interesting things feature-wise, but the SDK is a mess.
  - crla 10y ago
    I don't believe it is as bad as BoorishBears says. Yes, configuration changes cause a tear down and recreation of your view/controller layers, but there are several patterns to deal with this cleanly (view controllers whose lifecycle spans multiple instance of a view is one of the more common, with the view instances detaching/attaching as they come and go). If you use a Flux like pattern for handling application data state you don't even necessarily have to do that since your views are just observing data stores whose lifetime outlives the views anyway. As for asynchronous handling, there are quite a few popular libraries that are very powerful and make it easy to compose multiple asynchronous operations, update views on changes, etc - RxJava for instance has been pretty popular for the last couple of years and is very powerful, but has a steep learning curve. There are others such as Agera (from Google itself), as well as simpler async libraries like Bolts (similar to .Net task futures). The Android SDK itself does not contain much in the way to help with any of this though (I would avoid pretty much any of the async classes that come with the SDK such as Loaders and AsyncTask) - so you do have to research and learn about third party libraries to get to a state where you can write clean and concise code.
    - BoorishBears 10y ago
      Don't get me wrong, I don't mean to imply writing clean apps is impossible but I believe it's a fair assessment of the "state of the Union" for development. Even your comment kind of alludes to the mess: Yeah there's RxJava but it doesn't inherently solve the rotation issue because your Observables so you still need to persist the information needed to recreate them. And any long running tasks need a separate solution because tearing down the Observable will reset the operation Googles app development team made Agera which was widely panned as an inferior NIH RxJava Having your view's controller persist also requires custom logic because only your application will persist through configuration changes and even then the process can still get killed leaving you with nothing but data stored to disk via Parcelables or your own custom solution. Android Devs solved asynchronous operations, the problem is keeping those operations going after a configuration change. If the operations reference the view you'll get NPE when the view is destroyed while a job finishes, and if your view references the operation you need to lay down infrastructure to let your asynchronous operations exist completely separate of the view and be able to cache their results for when the view comes back. It's not impossible, everyone does it somehow, but it's created a lot of divergent theories on how it can be done
- vvanders 10y ago
  The databinding stuff seemed pretty half-baked to me last time I looked at it. Completely agree that Android is way behind the times with respect to common ui patterns.
- ex3ndr 10y ago
  > every time you resize your window the entire browser restarts and its up to your page to restore its state Wrong, it can be and often is disabled and windows are just resized without recreating of activities.
  - BoorishBears 10y ago
    Disabling configuration changes is a naive hack (half the people who do it don't even disable every configuration so their apps break on something as simple as plugging in a keyboard with USB Otg or more commonly, tablets). You're still supposed to handle all the configuration changes you disable yourself, and people rarely do. Disabling configuration changes is really for stuff like games where realistically the normal configuration change handling doesn't make sense and proper handling is as simple as resizing your surface or something. And the window thing was part of the browser analogy, not the Android one, but ironically resizing an Android window can force an app to switch layouts causing a configuration change. Windows actually add even more complexity because now apps have to differentiate (to keep the analogy going) between when the user closes the browser and when the user clicks away from the browser (nuances with how the window features interact with stop vs pause which affect stuff like video playback apps)
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]