42 ms·

It’s Been Real, Android: Why I’m Retiring from Android

• vans 10y ago
  The comparaison with JS is perfect. Like JS is the asm of the web ecosystem (no one wants to write its code just in JS, we generate it instead), default android and IOS way of programming have to be be generated. Try Xamarin [0] or the newcomer flutter [1]. It's such a pain in the ass to dev in raw android or raw ios, use multi platform sdks. And if you start with xamarin, you can target windows phone too, even if nobody cares ;-) [0] https://www.xamarin.com/ https://www.xamarin.com/ [1] https://flutter.io/ https://flutter.io/
  • rmsaksida 10y ago
    I've had some terrible experiences with Xamarin. The tooling is very rudimentary compared to Android Studio, performance is subpar, app size is huge, and development is so slow it's maddening. I wouldn't recommend it other than for some very specific use cases. I'd much rather deal with just plain old Android issues than wrapped-by-Xamarin Android issues and Xamarin-specific issues.
• simophin 10y ago
  i have to say, refusing/unable/lazy/ to learn is the most terrible thing ever happened to a developer. I'm always excited about new things even I have to learn them hard, even they start with poor quality, but I believe these are what make developers happy
  • Zyst 10y ago
    I feel you are concentrating on a very small and negative part of the post in a very disingenuous manner. I read the article more as: "I have found throughout the years I've become a decent programmer in iOS and Android, I'd rather be a good or excellent iOS developer." The end just briefly describes why he decided to go with iOS instead of Android briefly, but that's about it.
  • chj 10y ago
    OP is not lazy to learn, it is just that he finds out that learning android development is a poor investment. He would rather learn swift instead, which I think is correct.
  • yasth 10y ago
    Eh, I think it is a natural process though in one's professional life. Especially with something like phones where the complexity has just exploded within each platform. The number of ways to deploy code on iOS alone (ObjC, Swift, Cordova, React native, etc.) has increased rapidly, and the size of the system apis alone has increased massively. Some form of specialization is likely inevitable. There was a time when the web only had webmasters, and they did everything from devops to backend to frontend. Gradually it became handy for a lot of people to focus their professional career on one area they were particularly good at, especially to move to the absolute peak of their potential. By all means people should try out things, and keep up with things, but for a lot of professional reasons it makes sense to have a core competency. Of course it also makes sense to move that as needed.
  • wvenable 10y ago
    I have little patience for learning the same thing over and over but only slightly different. It's just a big waste of time. There's no enjoyment or happiness down that path. Learning totally different and interesting stuff, that's a whole different story.
  • taneq 10y ago
    You're clearly still young and haven't yet burned out on learning new technologies that (a) are just poorly thought out rehashes of existing technologies, with everything renamed to sound new, and (b) go obsolete within a few months, flushing your precious time investment down the toilet with them as they go.
• cyberferret 10y ago
  I found that as I get older, and still try to learn different languages and platforms, that I have to try and work on my research skills as much as my coding skills. As the OP pointed out - straddling several languages means that syntax and keywords are not always readily apparent when you sit down to code, but knowing where to look for them and refresh your memory quickly becomes an activity all on its own. This from a guy who is a week away from being 50, and still occasionally puts a ';' at the end of his ruby code blocks.
  • shoover 10y ago
    I always thought those language/framework/library cheat sheets were for newbies only, but I'm beginning to see that's not entirely the case.
• tarr11 10y ago
  Interesting, I have avoided much mobile development for the past decade for the same reasons OP mentions. However, I have been drawn in by the promise of React Native, which addresses compilation time and cross platform concerns.
• virmundi 10y ago
  I don't think that the person is being lazy. I've tried my hand at Android. I will continue to do so. I don't like it for the reasons enumerated in the post. The whole damn thing is a hack at this point. No one has a good generalizable architectural model for laying out an Android project. Attempting to target multiple devices is truly a pain. You can do it. You have to really, really think about. You also have to end up making whole sub sections of your product for a specific form factor. I'm not saying that iOS is better. Don't really know. I've played with Swift and a few of the Apple tutorials. In general, I'm against the current incarnation of mobile. After years of having an Android (and now having an iPhone due to work), I switched to a Samsung Juke. That's right, a feature phone! The Android just got slower and slower. No updates, not improvements. Finally it screeched in my ears while working. I picked it up and slammed it on the desk (felt great for a week). Both iOS and Android are slow, overly wrought operating systems. That being said, unlike the author, I'll still use Android and iOS for my products. I have products that need to be mobile. They have to target the machines my customers have now. That also means that I'll have two native app code bases. I'll have to keep track of native app UX/UI standards. I'll have to keep such hardware around ('cause Android's emulator is still sucks when I've got an VM running).
  • gjolund 10y ago
    Double that complexity if you also want a web app that works across all modern browsers. I wish the big 4 would get their act together and stop pissing on each others legs. FB is the most recent entry into this clusterfuck. They should be ashamed of the Oculus/GearVR developer experience, it was the determining factor in my abandoning Oculus. It is the developer that pays the cost in the end.
    • deleted 10y ago
      [deleted]
    • pizzacowboy 10y ago
      Aw, that makes me sad. I've been telling myself I'm going to get into the VR scene and dive in with Oculus. I was hoping it would be a dev-friendly environment.
• ryandrake 10y ago
  Without mentioning which platform(s) I prefer, I have to agree with the author. On one hand, it's nice to be able to work cross-platform, and architecting your app such that you maximize code sharing is a worthy and satisfying goal. But quite a bit of code (the UI mainly) cannot be shared and it's kind of tiring to finish your Platform A app, look at it with pride, and then face the need to essentially re-write the exact same thing for Platforms B and C, only in different languages and frameworks "because platform competition". You're splitting your attention, expertise, time, and learning N-ways.
  • mentos 10y ago
    As a once iOS and Android Dev (before moving to game dev in UE4) I found the act of having to rewrite an app again on another platform a great way to refactor the code and do things better the second time around. If I had to go back though I'd probably try to find a way to do things once on the web, is React Native this?
  • rhizome 10y ago
    I don't get it. How can there then be all of these weekend tossoff games in the Play Store that work just fine? Unless I'm unclear on what you mean by "platform."
    • seibelj 10y ago
      An app that uses native UI widgets is very different from a game which uses a graphics engine. The game compiles cross-platform with minimal changes.
      • praneshp 10y ago
        Can you point me to a good resource for "a game which uses a graphics engine". Last week, I built both an android app and an iOS app, and would like to build something that compiles cross-platform to complete the set.
        • 10y ago
• seibelj 10y ago
  Unless you are writing a Tier 1 application that needs every fancy do-hicky, I don't see the point of 100% native anymore. Use React Native, then if necessary have a devoted native developer for each platform to handle parts that absolutely have to be executed in native and provide a JavaScript API. If you are a big company with tons of money, sure, create duplicate teams to make the same app for each platform. But if you are small or just starting, React Native is the best choice.
  • copperx 10y ago
    I'm all for write-once-deploy-everywhere, but React Native is better suited for apps that could be easily written web-only. Maybe I don't get what's better about React Native over a native app that is just a web view.
    • naiyt 10y ago
      > Maybe I don't get what's better about React Native over a native app that is just a web view. It's better because React Native is actually rendering native components. Stuff like PhoneGap never feels or works quite right as a side effect of being rendered in a web view.
      • wingerlang 10y ago
        I think his point is - why make a native app that just re-renders the data which you can just as well look at in a browser.
        • suprfnk 10y ago
          Next to the fact that something like push notifications require a native implementation, people like apps more. I'm currently working on a way to make our mobile-tailored website into an app, just because customers keep requesting a _real_ app instead of a webpage.
    • clay_to_n 10y ago
      React Native apps are written in JavaScript, but the components you use are wrappers for actual native view components. So you get native performance (the views can be GPU-accelerated), and native styles. I've been working with Android for a couple years, and (while I like it) it has it's warts. The architectural patterns required to keep a medium-sized codebase understandable are simply not agreed upon. There are lots of ways to do things, and (as the article points out) even the basic activity + fragment API's are very complex. I just started playing with React Native, after having some React experience, and it's a breath of fresh air. It feels like cross-platform without obvious negatives, and the rare bonus of being able to wrap + use native components or libraries whenever you need to. You can even share most of your code (even view code for basic views) across IOS and Android. React has a super simple API. The tooling is younger, but is out of the box faster to develop with than Android. That said, I haven't built a large app in React or React Native, and maybe it bites developers at some scale. No idea how it deals with long-running services, multiple threads, bluetooth or other hardware APIs. But for now, I'm very optimistic.
• ausjke 10y ago
  I worked on android for 3 years, then did something else for 3 years, now am back to Android, there are so many vendors selling android phones, so it shall work just fine I assume? or is it getting much worse for developers(system and app developer) these days?
• cageface 10y ago
  iOS has plenty of developer pain points as well, although in their case a lot of them are as much a result of dumb Apple policies as they are technical mistakes. I'm going the other way. After six years of iOS work I've had enough. I still think the web is the smart long term bet so that's where I intend to focus my energies.
  • copperx 10y ago
    I agree. However, I would have never thought that developers would be so miserable in 2016. Say what you will about the desktop; developing for it was a pleasure (except for you, Win32 API) compared to what we have in 2016.
    • rpeden 10y ago
      The sad part is that things were looking pretty hopeful in 2008-2010. I particularly liked Cappuccino. It's basically a port of Cocoa to the web. You could design your interface in OSX's Interface Builder. The project is still around and is still being worked on. Sproutcore was pretty similar, and is also still around. Neither of them are being developed as heavily as React or Angular 2, but they have both been mature for a long time, and perhaps don't need a lot of work to be done on them. Maybe it's just me, but I still find 280Atlas[1] and 280Slides[2] more impressive that many web apps that ship today, and they're nearly 10 years old and ran in browsers far slower and less capable than what we have now. I actually think more developers would frameworks like these if they didn't feel they had to stay on the latest and greatst JS treadmill to remain employable. And I write that as someone who likes React and Angular. They're both sane ways to develop complex apps, but they don't feel that much better than what was possible 8 years ago. [1] https://www.youtube.com/watch?v=ouzAPLaFO7I https://www.youtube.com/watch?v=ouzAPLaFO7I [2] https://www.youtube.com/watch?v=tMZwfh-_QEQ https://www.youtube.com/watch?v=tMZwfh-_QEQ
  • Humdeee 10y ago
    Very true. Having done both professionally however, I can say Android is on another level with frustration and tooling problems. Yes, I've become biased, and yes, I will remain much less enthusiastic to take on an Android project. I appreciate both platforms, but man, iOS allows me to sleep a bit better at night.
• credo 10y ago
  Like the op, I do both iOS and Android development work. However, as an indie, my platform preference is primarily market-driven. So most of my work has been on iOS Unlike the OP, I like and use Android AsyncTasks. I have no problems with Android fragments either. However, I did have a lot of other concerns with Android - primarily the low quality of Google's SDK for Android. Here is what I wrote about it https://blog.cascadesoft.net/2013/12/31/the-bigger-problem-with-android-bugs-and-quality-not-fragmentation-per-se/ https://blog.cascadesoft.net/2013/12/31/the-bigger-problem-w...
  • popmystack 10y ago
    >primarily the low quality of Google's SDK for Android. This has always been my biggest frustration with Android. I've written a few applications for the platform, and while their architecture leaves a lot to be desired I've never had any real problems with it. However, the immense disappoint and anger that comes from their SDK idiosyncrasies is astounding. Google really just hates stability and nice API's, in my opinion. Everything from GAE to Android, it's always just so terribly frustrating to keep track of any one-off decisions they make without any form of actual communication from the development team. I've been writing Android code since the G1 days.
  • cloudjacker 10y ago
    > However, as an indie, my platform preference is primarily market-driven. What do you mean? Where craigslist entrepreneurs and seed stage startups want iOS apps?
• cloudjacker 10y ago
  lol, I've had those sentiments employers are also skeptical you are content with both, I wouldn't consider it a value add unless you can land a lead position for a mobile team aside from working on multiple platforms diluting your experience with the latest development patterns, it is just as easy to be stuck maintaining an old project or legacy code with an employer. This isn't unique to mobile of course, but multiple platforms really exacerbates how fast it happens.
  • cloudjacker 10y ago
    *competent, not content
• ClayFerguson 10y ago
  Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet. I don't know from experience. I've been a Java DEV ever since MSFT tried to hijack the Java language with a proprietary version back in 1998, and I abandoned MSFT and never went back. I can imagine trying to be both iOS and Android developer would be about as insane as trying to be both .NET and Java developer. Oil and water. Doesn't mix. For me there is one and only one word that i need to hear to know I want to avoid iOS: "proprietary". I wouldn't touch any Apple product with a 10ft pole. I like open systems, and Apple is all about maintaining their closed little private invite-only walled-garden of an ecosystem. No thanks. They may be successful a while longer but "open" ALWAYS wins in the end.
  • matwood 10y ago
    I did both iOS and Android for a few years and it was fine. The only issue was the lag time for our customers for features across the platforms. With a small team it takes a lot of time implement on both. We have since rewritten the app as a SPA app and share 90% of the code across the web and Android/iOS using Cordova.
  • cechner 10y ago
    > Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet I hope not for my sake :) Im currently contracting writing C++, but my previous contract was with the ASP.Net stack. Before that I was working on a lot of Java services (introduced Scala to good effect) I also have started a side business helping small companies by making small apps helping with their everyday stuff - sometimes Ill make iPad apps with Swift, but more recently Qt/QML to make something that runs on both OSX and Windows desktops natively. I also made (very small!) web apps for them hosted on both Azure (MS stack) and AWS (linux stack) After a while learning the core aspects of a new language doesn't take very long, and they generally have to address the same high-level concerns. That said, learning iOS development was a continual hassle but feels like it was worth it to have a native app that I can deploy easily using HockeyApp etc. edit: I will undermine my whole point here by saying that I abandoned a personal Android project because the dev environment felt so ad-hoc and duct-taped. I spent a ridiculous amount of time trying to get the simulator to render GL properly without any luck (on Windows)
• clumsysmurf 10y ago
  A while back, Dianne Hackborn famously said: "We often see questions from developers that are asking from the Android platform engineers about the kinds of design patterns and architectures they use in their apps. But the answer, maybe surprisingly, is we often don't have a strong opinion or really an opinion at all." (1) While that may have been a lofty ideal, in practice Android has many strict requirements on how you partition your code between Activity, Fragment, ContentProvider, and Service classes. Never mind testability and all the new semi-opaque / intelligent battery optimizations Android applies to your app. After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. This is a frequent and necessary thing to do, and also quite awkward. The result is unnecessary complexity that often and easily permeates the code. Dianne says they have no opinions on architecture, but where I disagree is concurrency is an architectural concern and there are definitely many corner cases & snafus mixing that with Android APIs. (1) https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU
  • gjolund 10y ago
    This is an excellent comment, and it mirrors my experience with android also. Most of the responses Ive gotten from coworkers is "what would you change". I have a hard time answering that.
    • cel1ne 10y ago
      If one were allowed to break backward compatibility I could come up with a list of changes easily.
      • gjolund 10y ago
        But that is the crux of the problem isn't it? Device/OS proliferation has made android dev pretty complicated these days.
        • cel1ne 10y ago
• mahyarm 10y ago
  We adopted buck at work for android & objective-c ios and it's been amazing speed & low-bullshit wise: https://buckbuild.com/setup/getting_started.html https://buckbuild.com/setup/getting_started.html If gradle is killing you, I would suggest trying it out. Warning: we have a few guys in a mobile developer experience team, so I don't know how good it is for indies.
  • iainmerrick 10y ago
    I have the opposite experience -- I tried Buck because I really wanted a Blaze/Bazel clone (it wasn't open source at the time). It works but I find it very slow. My project involves lots of native code and genrules, though. If you're mostly building Java code I imagine Buck might work well. If starting from scratch I would try Bazel first.
    • krschultz 10y ago
      Buck's speed improvement is heavily dependent on breaking your code into modules. What was your project setup like?
      • iainmerrick 10y ago
        I have 2300 lines in about 40 BUCK files, plus 500 lines in 2 DEFS files. Just parsing the BUCK files seems to take an inordinate amount of time (tens of seconds from cold).
• ojm 10y ago
  Cached version as it is down: https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/+&cd=1&hl=en&ct=clnk&gl=au https://webcache.googleusercontent.com/search?q=cache:dFoTDF...
• georgeecollins 10y ago
  Gradle has problems, but it doesn't seem worse to me than making builds in Eclipse was. I would love to hear why people think it is better or worse. I agree multidex is terrible. Google please fix this. I do not know when I should use a fragment instead of a view. I know the layout reasons google gives in their developer guide but I don't think I have seen a piece of code that really uses fragments that way. So why? I do like Android development though.
  • fractalwrench 10y ago
    Gradle is just incredibly slow on Android compared to Eclipse. particularly with larger projects. Instant Run has helped alleviate this to some extent, but it's still not uncommon for a build to take 2+ minutes. I guess this is mostly due to all the resource crunching that Android does, and the fact that Android Studio doesn't perform incremental compilation by default. Another annoyance is that every time a minor change such as incrementing a version number is made, Android Studio grinds to a freeze syncing gradle files.
    • distances 10y ago
      We are building a bit larger and more complex Android project, and every now and then just the Gradle part takes over 5 minutes for me. Just the Gradle syncing, before actually compiling anything. I think it's Gradle getting somehow into knots and taking a while to resolve everything -- I've got a very beefy computer so it's not about processing power. Gradle is just ridiculous.
    • AstralStorm 10y ago
      Incremental compilation seems to be on for newest release of Gradle, but Android is still on 2.x due to the plugin. For our project, the most time consuming part is... Packaging. Making apk splits is slow, why does it zip the whole thing again if it is just replacing resources?
      • vardump 10y ago
        > why does it zip the whole thing again Maybe fragmented zip files with holes inside are undesired? Because that's what you get when modifying zip files in-place.
• wiradikusuma 10y ago
  The link from HN redirects me to https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/wp-admin/install.php https://raptureinvenice.com/its-been-real-android-why-im-ret... with this error: The raptureinvenice.com page isn’t working -- raptureinvenice.com redirected you too many times. Anyone having same problem?
  • dingdongding 10y ago
    Yes. I faced similar problem so I went to Google Cache. http://webcache.googleusercontent.com/search?q=cache:https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/ http://webcache.googleusercontent.com/search?q=cache:https:/...
• Ologn 10y ago
  I don't think lifecycles, phone rotation etc. are much of a problem, because once you know them, you know them. I think the problem is Android keeps changing the current best practices. I'm not even sure how to know what those are - if you enter code from the Android tutorial into Android Studio, much of it is deprecated. In January 2011, the way to do tabs in Android was via LocalActivityManager. Then in February 2011, ActionBar.Tab was added. By July 2011, the LocalActivityManager way was deprecated, and ActionBar.Tab was was pointed to as the way. Then in November 2014 with the release of API 21, ActionBar.Tab was deprecated ( https://developer.android.com/reference/android/app/ActionBar.Tab.html https://developer.android.com/reference/android/app/ActionBa... ). So what do we do for tabs now? Who knows? The most current tutorial ( https://developer.android.com/training/implementing-navigation/lateral.html#tabs https://developer.android.com/training/implementing-navigati... ) is still telling you to do it in the way that was deprecated two years ago. That's what is maddening with Android - they have a way to do tabs, add a new way, deprecate the old way within five months, then three years later change their mind and dump the new way - without changing the documentation and telling you the new way to do it, it's all just deprecated. The tutorial is full of deprecated code. What's the new way to do it? Who knows? A few years ago some corporate director at Google must have gotten a directive to push Google TV. So then they were pushing all apps to work with Google TV. I guess that fizzled out. The latest thing is making sure our legacy apps work with Chromebooks which allow multiple apps on the screen at the same time. I don't mind Google and Android continually chasing the new shiny, but I wish they wouldn't have a tutorial full of deprecated code, I wish they didn't change how they do things such as tabs every three years (three new ways to do it in three years). I wish they fixed bugs instead of implementing new features. On code.google.com, developers post bug reports, then many other developers jump on saying they see the same thing, and...a few years later, it just closed for being obsolete. Another example of continuous churn - Google Analytics looks like its going by the wayside, to be replaced by Firebase. Admob is now integrated into Firebase. So that's a whole other thing that needs to be redone in an app. You have to run to stay in place.
  • taneq 10y ago
    I've only dabbled in Android but this is what drives me mad. I spend a month digging in and learning "how to develop for Android" and then six months later when I go to use that knowledge for my real job, everything's changed. What was best practice last time I looked is now frowned upon, deprecated or flat-out broken, whole generations of new best practice have churned by, and current 'best practice' isn't compatible with any handset more than three months old. If you're doing it 40+ hours a week then maybe the ongoing investment is worth it but to me it's a colossal waste of time.
• rtpg 10y ago
  Kind of an OT whine relative to the contents, but I'm still extremely frustrated at how hard it is to get other languages working on Android due to the multidex-style issues. Google should be spending millions being able to get app development up and running in something like Python. Have your app up and working in 2 minutes without having to learn Java. It boggles the mind that this isn't the case, and that the current tooling environment is soooo impossible to wrap ones mind around.
  • distances 10y ago
    Nah, they should just embrace Kotlin, even if it wouldn't solve the platform API issues. Java is not for this day and age, but frankly so wouldn't be Python.
  • pjmlp 10y ago
    Many developers on the core Android team are former Sun employees and most likely very Java biased.
  • GeneralTspoon 10y ago
    The same could be said about any platform - e.g. why can't I write my iOS apps in python? Transpiling languages like that nearly always ends up messy, and adds another layer of potential bugs to the system. Taking the time to learn the platform will end up better in the long run (at least with the current state of transpilers). And as it stands, you can write Android apps with a native UI in Java, Kotlin, JS (React Native) and C# (Xamarin). And you if you want you can write business logic using any language that will compile to a C binary (using the NDK).
    • rtpg 10y ago
      So the multidex issue I was referring to makes it pretty hard to write things that will compile to C with the NDK. In order to get any access to the Android APIs, you have to do C-JDK bridging through JNI. And in android VMs, there's a hard limit on the number of symbols you can reference in the lifetime of an app. It's the equivalent of if python was like "yeah you can use the standard library, but only up to 100 functions!" iOS, since it goes through the LLVM framework stuff, doesn't have that many barriers to transpiling from other languages. You can just do raw function calls to the OS libs. But Android doesn't allow this, forces you to go through the JNI, and makes you have to work around this symbol limit.
• MaulingMonkey 10y ago
  > Google’s adoption of gradle has been a disaster and proved to be a terrible decision. It did help out with some previous issues, namely multiple app targets, but it’s slowed down compilation severely. It also makes for masochistic configuration files with major redundancy and fragmented dependency hosts. Getting an app to compile shouldn’t be a challenge. The only thing worse than gradle is ANT, which it replaced. > Wait, what is picasso? Oh wow, I hadn’t heard of that one…I was busy learning Swift. I just minimize the amount of platform specific tech in the codebase as much as possible. RxJava? That's going to be real fun to port... Ahh, this didn't even touch on my least favorite part of Android - command line tools that tell you they've "successfully" deployed APKs. And returned successful return codes. That in reality silently failed due to ever so slightly loose USB connections. On the plus side, they finally fixed https://code.google.com/p/android/issues/detail?id=197287 https://code.google.com/p/android/issues/detail?id=197287 in Android 7.0 it looks like...? I'm trying to remember if that was the bug to blame for my last 16 hour day...
  • rifung 10y ago
    > The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago
    • stuaxo 10y ago
      Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each other is a classic). With Android, they seemed to change the build files every minor release (my info may be out of date here).
      • MaulingMonkey 10y ago
        > Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each other is a classic). Dependencies were a mess. Depend on A and B with both depend on C? C gets pulled in twice, build fails. Workaround? Hack up A to depend on B instead, and have your project depend on A. Surely adding a new dependency isn't supposed to involve mucking with the build files for half of your existing previously fine third party libs just to get the bloody thing building again - such that all dependencies are only referenced once, yet such that every library has it's dependencies indirectly satisfied by whatever it's been configured to depend on. I assume I was doing something wrong. I probably sunk a good week into consuming docs and trying stuff out to figure out exactly what. I still have no clue. My coworkers couldn't figure it out either. I wrote wrapper scripts - and later a full blown partial adb wrapper - to fix the silent deploy failures, after one too many hours of wasted debugging sessions (caused by debugging stale builds) made me crack. A few commands to check file sizes and timestamps... a few regular expressions to parse the results... a few debugging sessions when e.g. the installation defaults for "adb logcat" log output format changed between SDK versions... After reaching a similar snapping point for ANT, I took the slightly less drastic option of switching to gradle for the next Android project I tackled. I remember gradle being merely 50% as terrible as ANT. I seem to have successfully repressed many of my more detailed memories of dealing with both. Huzzah!
• tananaev 10y ago
  I think there are no developers that are true experts in both Android and iOS platforms. Every developer I know either leans towards one platform or another. There are also developers who know both platforms pretty well, but I won't call them experts in either. I consider myself an expert in Android development. The only point that I agree with is multidex, but there are historical reasons for the limitation and I think Google engineers are trying to fix this problem or make it as simple as possible to use multidex. I occasionally do iOS development and some things in iOS don't make sense to me, but I'm sure they would be obvious for an iOS expert. My advice for mobile developers or future mobile developers is to specialize in a single platform that you like more. For me it's Android. For the author of the article, it seems to be iOS.
  • tluyben2 10y ago
    I am an expert in iOS dev but I use and want to like Android. It is quite annoying... I really do not like the walled garden of Apple and on Android devices, even cheap MTK ones I am quite handy at installing what I want, but for some reason I find Android development a real pain compared to iOS where I find most older things (stuff, as it goes in life, needs to mature) very obvious and easy. I would say what most annoys me about iOS is the GPL thing which is the reason, among others, there are no emulators in the Appstore, at least no relevant ones. As owner of a museum and fan of old machines I cannot do without emulators. On my Android tablet I have around 50. Emulators is a niche but no GPL is hampering a lot for everyone on iOS.
    • TheCoreh 10y ago
      The GPL incompatibility issue has nothing to do with Apple not allowing emulators. (After all there are BSD/MIT emulators) They don't want (non-sandboxed) interpreters running unreviewed code. Right now the only interpreter allowed to be used with downloaded code is webkit's JS JIT.
      • tluyben2 10y ago
        There are multiple reasons as I said: one is the one you say but some emulators I use are under the GPL and use many GPL libs. But yes the other restriction sucks too. The point was cannot normally use emulators under iOS which stands, whatever the reason may be.
• keyle 10y ago
  I get a 404 on that article. Maybe the DB is having issues still. A cache here https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/ https://webcache.googleusercontent.com/search?q=cache:dFoTDF...
  • zouhair 10y ago
    Or here http://archive.is/girlg http://archive.is/girlg
• rcheu 10y ago
  I've been doing Android development since the G1 release. I agree with most of these points, but think they're also not a huge deal after you've been working with the platform for awhile. The biggest issue is by far the iteration speed though. Build/install take way too long--Android Studio for some reason takes 15 seconds to start my app even if no changes have occurred. Instant run is supposed to solve this, but it's too buggy to be useable right now. Sometimes your changes just don't apply, but you never know if that happened or you messed up your fix. I actually preferred ant since I better understood what it was doing. Gradle error messages are often very vague and confusing, and build times are strangely inconsistent.
• exanddevxyz 10y ago
  What is surprising is that google with their much celebrated hiring practices for senior devs managed to hire no one who could say no to such insanities like Fragments and Async and the entire Android dev platform/toolkit as it stands today. Apple, formerly famous for being design hippies who couldnt care less about performance, have topped the mobile performance charts for nearly a decade straight now and with no end in sight. An entire decade! They merely had the wisdom of not choosing java to base their platform on.
  • ec109685 10y ago
    Where do you base you claim about apple not caring about performance? They have pushed the performance envelope ever since the first Apple computer where Woz built it with way fewer chips than their competitors. Their ui's have always demanded extreme performance.
• bitmapbrother 10y ago
  I did a search on Google Play for apps from this developer and all I found were: 1. A work in progress To Do list app with 1-5 installs: https://play.google.com/store/apps/details?id=com.raptureinvenice.taskolo https://play.google.com/store/apps/details?id=com.raptureinv... 2. A Craigslist notifier with 100-500 installs: https://play.google.com/store/apps/details?id=com.raptureinvenice.hawkeye&hl=en https://play.google.com/store/apps/details?id=com.raptureinv... I don't mean to belittle the qualifications of this developer, but if his Android applications are any indication of the quality of his future iOS applications then good riddance on behalf of Android users.
  • V-2 10y ago
    What does it prove? Not everyone is an independent developer / single-person software house. The way it goes, more often than not, is that people write apps for various companies and then these apps don't get published under their own name, but these companies'. Something someone uploaded to Google Play individually could be just their hobby project created in their spare time. I haven't got anything in Google Play in my own name, and I've been an Android dev for several years, writing serious software for big businesses.
• thirdreplicator 10y ago
  Given all the grief expressed in the post and the comments, it seems like if someone architected a really nice, developer-friendly native mobile API for any platform you would get droves of devs flocking to it.... Despite the two major players, the market seems wide open as long as they focused on the development experience like what Matz did for Ruby... Programmers are customers too! :)
  • JamesBarney 10y ago
    I've heard a lot of praise for the Windows phone developer experience, but what really matters is the audience. Dev's flock to the audience. Even just a small pay difference will dev's to deal with the most terrible of developer experiences(ex. Sharepoint)
    • pjmlp 10y ago
      I do hobby coding between Android and WP, and do love the experience. Microsoft might have lost the mobile war, but they are on good track to win the hybrid laptops one.
    • andromeduck 10y ago
      Well it's good as long as you're okay with being on Windows but that can be a pretty big barrier
  • naiyt 10y ago
    React Native is getting there. It's still early software with a lot of problems but it has a lot of promise. My anecdotal experience as someone learning mobile development was that React Native was a lot easier to pick up and learn than native Android development. Despite a large number of issues the developer experience has been really slick and I've been able to iterate much faster. Give it a couple of years and I think it'll be exactly what you're asking for.
    • lacker 10y ago
      it has a lot of promise Glad to hear it ;-) I'm curious, what have been the main issues for you?
• EddieSpeaks 10y ago
  Which is Why he should move to Xamarin. Xamarin Forms can let him maintain one codebase over multiple platforms and leave the rest to convention
• chickenbane 10y ago
  I do not think writing Android apps is straight-forward and would not recommend it to new developers or engineers like the author who want to do other things like iOS. People's expectations for apps is only getting higher, and there are many, many things you need to understand in order to be a produce great Android apps. As an example, another commenter noted the Android platform engineers not being opinionated about application development as a "lofty ideal", but more likely this is a consequence of the framework team having enough on their plate. The vanilla Java AOSP API surface (not even considering the NDK, support libraries, Google Services, etc.) is enormous. The Activity lifecycle is complicated, and it's very easy to leak memory or write spaghetti code. There are many ways to do similar tasks, and these also change with time. Etc. That said, I love being an Android developer, and it is improving at an accelerated rate. To start, Android Studio and Gradle are far superior to the pain of getting Eclipse, Ant and the SDK tools working together. Yes, Swift is awesome and shiny, but there is so much more to a platform than the language. Java has excellent tooling - great support for debugging, monitoring, automated testing for CI/CD (automated UI testing still needs work, but also improving), static analysis, etc. The support libraries are also a godsend, enabling you to make an app that looks modern while being frequently updated and handling a lot of the compatibility headache from the platform's diversity. Finally, there's a lot of great content online. The conferences are great and its expected to see their content on YouTube. Google's Android Developer YouTube channel is also fantastic (shout out to Jo and Ian!), and Google is slowly but surely improving the developer docs and integrating their sample code into Android Studio. So yes, you do need to understand the new functional reactive approach. You need to know how to write a Gradle build. You have to understand the complexities of proguard rules. It's all pretty frustrating. But I also feel that many of the skills are more easily transferrable - I can also write a Gradle build for a library or I can use IntelliJ to better debug a servlet. With Swift and iOS, there's only vendor you can build for.
  • taplogger 10y ago
    > So yes, you do need to understand the new functional reactive approach. You need to know how to write a Gradle build. You have to understand the complexities of proguard rules. It's all pretty frustrating. But I also feel that many of the skills are more easily transferrable - I can also write a Gradle build for a library or I can use IntelliJ to better debug a servlet. With Swift and iOS, there's only vendor you can build for. I couldn't agree more. Android experience is hard-won. You have to 'discover' and develop an intuition for application architecture and how to use UI components effectively over time. The upside is a well-architected Android application --using tools like MVP, dependency-injection, and functional-reactive programming-- will have the positive characteristics of a Service Oriented Architecture: encapsulation, statelessness, composability, loose-coupling. This may seem like overkill for an app, but it minimizes the effect of UI lifecycle issues novice and intermediate developers tend to complain about. Architect a few Android applications in this way and you gain valuable experience composing abstract services together. A competency that is transferrable to backend services and other platforms.
• ensiferum 10y ago
  Yeah well, Craproid APIs are awful. It's gotten marginally better in tooling (the new IDE framework shits itself like only half the times compared to the Shitclipse based one), but there's still just too many brainfarts in the APIs. And ofc the implementatations are super fragmented and buggy. Here's a case in point: Androids MediaPlayer and its state diagram. This is pretty straigthforward pipe to the underlying Khronos OpenMAX API (that is totally brain damaged and horrible by itself). https://developer.android.com/images/mediaplayer_state_diagram.gif https://developer.android.com/images/mediaplayer_state_diagr...
• cel1ne 10y ago
  Allow me to repost two of my rants against android from a while back: https://news.ycombinator.com/item?id=8328646#8329034 https://news.ycombinator.com/item?id=8328646#8329034 https://news.ycombinator.com/item?id=9475825#9476547 https://news.ycombinator.com/item?id=9475825#9476547
• z3t4 10y ago
  I see two types of dev methods 1) Write it all down, read through the code a few times. Then compile and do a full test. 2) Write in steps, compile and test after each step. The later is a Pita on low level. And produce more bugs.
  • newscracker 10y ago
    Regardless of the platform, for any application with a non-trivial amount of complexity, iterative development is the best approach. I don't understand how anyone could "write it all down, read through the code a few times and test" and not produce a buggier application that doesn't meet most expectations. It does help to do some initial design work, create abstractions, loose coupling, etc. Iterative development does not mean jumping into coding without a high level plan on how to create the application pieces and how things would work (or do what's called as "cowboy coding"). With the amount of complexity involved in developing applications, considering the architecture, design, interactions between application components, error handling, different classes of platform APIs, UI, UX, state management, concurrency, hardware configurations to support, and many other things, I doubt if any human could really keep all that in one's head and really work through all the possible ways that assumptions during coding would get beaten, when compared to a real execution of the application and using that practical feedback in changing, fixing and improving things.
    • z3t4 10y ago
      I think everyone prefer iterative development. I love web dev because I can get instant gratifications (no compile time). I think it's mostly because I'm lazy though. I also manage a legacy system where I make hot fixes in production, where setting up a testing environment is not practical. While I do introduce bugs, they are far less because I'm forced to plan carefully, and know how everything works. One problem with development is that it's hard to predict what will happen, and thus it gets difficult to make estimates. But if you carefully analyze and plan, things will go much smoother.
    • spdionis 10y ago
      You are confusing scopes here. The parent almost surely meant those approaches applied to a single task (meaning a few hours to a day of work), not to building an application.
• arviewer 10y ago
  I get redirected to the Wordpress install page, which cannot connect to the database? https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/wp-admin/install.php https://raptureinvenice.com/its-been-real-android-why-im-ret...
  • cerebellum42 10y ago
    I just get infinite redirects.
• lubonay 10y ago
  I like comparing iOS to Android development as similar to playing Mario Kart and Dark Souls... It truly is a mess and I won't be surprised if/when someone releases an Android SDK SDK (SDK squared!) that generates all the horrible boilerplate so that you can start a network request, rotate your device and get the result in your view with no additional headaches.
• amelius 10y ago
  I'm not an Android developer, but I've seen my Android phone and tablet greatly deteriorate in performance over the last couple of years, mostly due to Android updates which were forced on me. I rarely use my tablet anymore because of this.
  • facepalm 10y ago
    That is the same with all computer platforms, though. I think it is OK if companies have a limited time of support for their OS, but you can debate how long it should be. With Android, it is also the responsibility of the phone manufacturers, not just Android/Google alone.
    • e40 10y ago
      This is certainly true of Windows (which I don't use anymore on the desktop). Until as late as Windows 7, I would do a wipe/install every couple of years, just to get my performance back to the way it was after a fresh install. I haven't done with this macOS, but I've heard of people doing this.
      • facepalm 10y ago
        Even with many Linux distibutions you can't run the latest version on older Computers anymore. But at least you can probably find a special Linux for older hardware.
      • deleted 10y ago
        [deleted]
  • e40 10y ago
    I've heard this from a lot of family and friends, and they almost always get the performance back when they reset the device and all the apps are reinstalled. A friend just did it with his Note 4 (or 5, not sure which).
  • antocv 10y ago
    Same experience here. My battery lasted from 100% in the morning down to about 15-20% just after lunch. Thats crazy. Then I removed all Google apps, Play services, everything to do with Google gone, wiped with a reinstall. Replaced with free open source alternatives, such as OsmAnd and K-9 Mail. Now the battery lasts 2 days! Yes, 2 whole days! Yesterday morning I had a full charge, now more than 24 hours later it is still at 46%.
• jamesvang86 10y ago
  Android is just one of those Big Corp projects were you hastily throw enough shit at the wall and see what sticks. It wasn't "designed", it's just the way it came out.
• chajath 10y ago
  What takes 3 hours for ios development takes 3 days for Android. Things are little bit better now that android studio is maturing, though.
• mobiuscog 10y ago
  Android should drop Java. It's nothing like writing 'normal' Java, and the baggage that is bought along isn't worth the effort. I like Java. I hate Android development.
  • chii 10y ago
    Other than the slightly different standard libraries, what else is different? Android Java is effectively the same as java 7, and any difference is solely attributed to library/SDK/api.
    • pjmlp 10y ago
      They don't support all the language features, specially the ones that make use of the new bytecodes. This will only get worse when Java 9, specially Java 10 gets released.
      • osweiller 10y ago
        Android supports 100% of Java 7, and with a new compiler ("Jack") it supports most of Java 8. For an average Java developer, it is absolutely a completely vanilla Java experience, and Android developers can pull in virtually any mainstream Java project or code with ease. The root claim is utter nonsense. This whole submission is just garbage -- a developer who is terrible at Android "retires" from it. The world doesn't care. (yes this post will be dead, courtesy of the utter decline of HN)
  • creshal 10y ago
    Do you still need to do manual malloc/free inside Java code to handle images in Android? That crap tripped me up when developing for it ca. 2011.
    • pjmlp 10y ago
      Yes, they optimized it and did a few changes in the way things work, but you still need to watch out. https://developer.android.com/training/displaying-bitmaps/manage-memory.html https://developer.android.com/training/displaying-bitmaps/ma...
• tn13 10y ago
  When I started development on Android platform I was told that we should not do IO on UI thread. Fine enough. What is the alternative? Every tutorial out there including Google's suggested AsyncTask. Only after few weeks I learned that we should never use AsyncTask for IO because internally it uses a threadpool of hold your breath 2 threads ! So how do I make all my REST requests ? Through something like Volley. This library is even more disgusting as it does not support some simple urls such as http://example.org/?id=1&id=2 http://example.org/?id=1&id=2. So I turned by focus on Services only to learn later that Services are meant for background tasks but run on UI thread. The best approach to do your own IO is through IntentServices. Something that should have appeared in the first tutorial.
• gagabity 10y ago
  As an Android only Dev I cant disagree with any of his reasons, the tools especially are just terrible, its not unusual to spend hours trying to figure out why my project will not build, this is compounded if you live in a country with poor internet connectivity, GB sized updates to the tools are not fun.
• izacus 10y ago
  Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze. If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling. The most useful things you can do for yourself currently are: * Adopt Kotlin as a language. It's not all that different from Swift, comes with IDE support, tiny standard library and really fixes the pain of Java 6. * Use MVP patterns and its friends. There are a few libraries which take most of the pain of lifecycles away. * Use RxJava, Retrofit, Glide, etc. libraries that make your life easier with concurrency. A lot of these tools are better and easier to use than what even exists on iOS. Using AsyncTask in 2016 is just silly, it was never a good API. * Use Gradle! Driven by its scripting language, you can do so much to script and automatize your build. Other than that, I agree, after years of development: * Some Android APIs just aren't well thought out. * Gradle badly needs performance improvement. * State of NDK is just sad. Fixable, but sad. * MultiDEX is a result of a very very dumb decision in Android 1.0 and it's going to hurt us for a long time :/ All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had. The blog post is somewhere on the level of someone complaining about IE6 JavaScript bugs when we've already moved on to React and are dealing now with very different issues. (And no I'm not saying Android is great or even a great platform. It's not. It's just that, just like on Web, you can do a lot to fix major pains.)
  • ilogik 10y ago
    Is there a tutorial or book that you can recommend for a newbie to get started with Kotlin,MVP, etc?
    • on_and_off 10y ago
      There is a great google repo with many architecture samples, including some MVP ones : https://github.com/googlesamples/android-architecture https://github.com/googlesamples/android-architecture For kotlin, no book needed. Go to the language website, read the introduction, maybe a couple of pages on the language features and then complete the kotlin koans. It will give you an overview of most of the language features. After that, find an android project written in kotlin. Here is one : https://github.com/LostInContext/LostContext-App https://github.com/LostInContext/LostContext-App (there are many others) . Configuring an android project in kotlin the first time can be painful, especially if you have some code generation (dagger, databinding, ...) , so it is way easier to have a working sample to work with.
• digi_owl 10y ago
  After writing a comment elsewhere i find myself wondering if why iOS is preferred, is that once an app is launched the app can behave pretty much like they could back in the dos days.Each app its own island, having the run of the device until the user hits the home button. Android on the other hand is more about stitching apps together into a larger whole via intents. Thus you have not not only care about what the user will see and interact when tapping the icon in the launcher directly, but also when getting a intent from another app. And most Android apps seems to fail on the latter. Various IM apps and such have been notorious for not going back up the intent chain when hitting the back button.
• tabulatouch 10y ago
  I've never been an Android developer, but i am happy Xamarin (Forms) developer. It is not without some hassle, need to deal with a little amount of platform-specific code, but it's the way mobile development should be in 2017. Code the experience and functionality, do not loose (too much) time on platforms.
  • pier25 10y ago
    Last time I checked Xamarin Forms about a year ago it was still limited. Is it better now? What are some of its limitations?
    • rpeden 10y ago
      It's still limited in that it's not a good choice if your app requires UI functionality that is very platform specific. I think that's intentional - it isn't intended to be the right solution for every application. It's still a good choice if your app mainly involves displaying lists and tables of text and images, and data entry forms. The cross platform Map control works quite well too. I don't remember exactly what is different now from a year ago, but if you list a few of the limitations you faced, I can tell you if they still exist. A quick look at the Pages, Layouts, and Controls section of the Xamarin Forms page might tell you if they've added things that were missing last time you tried it: https://www.xamarin.com/forms https://www.xamarin.com/forms
      • pier25 10y ago
        Thanks for the info. From what I've seen things haven't changed much. The idea still seems to be that Forms is for simple apps that use a number of common components.
        • rpeden 10y ago
          Yeah, it is similar to React Native ins that way. There's a limited set of cross platform components. In both Xamarin and RN, though, you can also include your own platform-specific components/plugins when necessary.
• macco 10y ago
  I like Android development with React-Native and Clojure.[1] But this probably doesn't fit the bill for prof Android developers. [1] https://github.com/drapanjanas/re-natal https://github.com/drapanjanas/re-natal
• aw4y 10y ago
  oh you'll be missed. I've worked on Android for ages, I don't remember in the last 3 years of one single AsyncTask I've used.
• lucb1e 10y ago
  At least Android doesn't require me to buy a Windows license or Mac computer (not just the license: OS X requires Mac hardware which is notoriously expensive). I'll keep it at Android.
• StreamBright 10y ago
  Sorry for my ignorance, but wouldn't React Native help with these sort of problems?
  • rimantas 10y ago
    React Native does not help with any sort of problems.
    • StreamBright 10y ago
      I thought you can skip developing directly targeting Android and this pain described here gets wrapped nicely. Isn't this the case?
    • cageface 10y ago
      If you need to build an iOS and Android app and you don't need to really push the envelope on design then React Native is a godsend. It's not the right solution for everything but for that vast array of apps that are mostly just list/tableviews talking to a REST backend it's a massive timesaver. I've been doing native iOS work for six years now and I'd still recommend RN over straight native for a lot of projects.
• caretStick 10y ago
  Librarians often don't realize that they can't keep plugging in method bodies and get what they want forever. Engineering isn't f&@!ing Madlibs for Christ's sake. Learn to build things that will work 100% of the time and never compromise!
• teek 10y ago
  > Google’s adoption of gradle has been a disaster and proved to be a terrible decision. It did help out with some previous issues, namely multiple app targets, but it’s slowed down compilation severely. It also makes for masochistic configuration files with major redundancy and fragmented dependency hosts. Getting an app to compile shouldn’t be a challenge. To be fair iOS dependency management is also a huge pain. CocoaPods is worse than working with Gradle in my opinion.
• krschultz 10y ago
  I was an Android developer, then flipped to being an iOS & Android developer. I chose to go back to solely Android for similar reasons to the OP. It felt like it was impossible to be excellent on both platforms. I was struggling to keep up with the pace of change. I ended up choosing Android because I found more demand for Android developers in the market. I certainly understand some of the OP's frustration with Android development.
  • cloudjacker 10y ago
    Oversaturation of iOS devs. Many people chasing the perceived glamour, diluting each other's pie. There's a lot of silver lining to doing android development for other people. Inflated demand, and all the client side - server side fires have already been put out when the company did the iOS project. So I would say, easier or less stressful. But I've been at this for a while, so there's the possibility I'm just good at it.
• deleted 10y ago
  [deleted]
• pier25 10y ago
  Mobile development in general is a pita. We really need a native cross platform solution that doesn't involve either running a JavaScript VM (ReactNative, NativeScript), writing UI code for each OS (Xamarin), and doesn't rely on a WebView. Xamarin Forms could fit the bill, but last time I checked it wasn't there yet. What other option are there?
  • dmix 10y ago
    Has there ever been a cross platform solution in history that was superior to the native development platform unique to the OS? This seems to be the pipe dream that everyone repeatedly hopes for then gets burned. I'd actually prefer if Apple and Google had their own development platforms so there are competitive driving forces to improve the platform. It will also accelerate experimentation with new tech where one platform can validate one tech so the other can adopt it quicker. Then if you have a simple lightweight app you can use some form of cross-platform browsery JS app (about the only point where this makes sense).
    • pier25 10y ago
      Superior? Depends on what you are doing. Working with game engines is a joy since you write "client" code, so to speak, and the engine is compiled for each platform. QT is also really good, but also really expensive, and you lose native UI which can be a good thing or not depending on your use case. NativeScript is working on becoming a universal cross platform solution similar to ReactNative. It's already on mobile, and I've read there is a macOS version being worked on.
    • krakensden 10y ago
      Qt
• shams93 10y ago
  For me I quit android studio to use aide to develop directly on the device. I got the remix os tv box for $50. I got fed up with needing and ultra expensive machine to develop my free software. I don't profit from Android but aide enables me to continue to contribute free apps without bankrupting myself to run an expensive development machine to do hobby software.
• xHopen 10y ago
  I did the same years ago, I had to decide and... well iOS is a paradise compare to Android
• nurettin 10y ago
  I've recently been dabbling with the new android studio 2.x and It has improved considerably in the past 3 months. For a single application all I need is: - A main activity where I commit fragments to show stuff - A settings activity foryouknowwhat - A main application class to store all the data and state - Some model classes for downloading/parsing/storing/data - A service that can be used from my main activity and notification manager I've been at it for a few months and the experience hasn't been as terrible as described. (Yes I do have async tasks that update the UI)
• colund 10y ago
  I think it's good to remember that it goes both ways https://twitter.com/devunwired/status/786542912469213184 https://twitter.com/devunwired/status/786542912469213184
• tofupup 10y ago
  neat
• tofupup 10y ago
  neat
• tofupup 10y ago
  neat