Live data from Hacker News

Android platform engineer on application architecture

plus.google.com

81–90 of 124 posts

Re: Android platform engineer on application architecture

#81

This makes my head spin. Plenty of examples on developer.android.com use Activities, Services, BroadcastReceivers for things that go beyond what Dianne Hackborn is recommending here. It's like the Android SDK team want to have their cake and eat it too: "We've built a tremendously powerful and useful SDK. It really helps you build great apps quickly and easily." vs. "Oh, and, by the way, be careful not to misuse our…

Well, d.android.com exists to showcase the core apis. They can't possibly show you how to create an app with 3rd party components on top of a single activity. Just take the bear necessities from there add your own stuff on top.

Re: Android platform engineer on application architecture

#82

Earlier quoted context omitted.

26min into the 2014 Google I/O Android fireside chat: https://youtu.be/K3meJyiYWFw?t=26m Q: So I was wondering if you guys at any point considered the support -- the official support -- of the Scala programming language. I'm asking this question especially now that we all saw that Apple released Swift after 4 years of work. And I think that Swift allows for things for iOS developers that we can't do in Java with the…

I gave up on watching those Android Fireside chat sessions because of the horrible jokey way in which so many valid concerns end up getting dismissed, every time.

Standard Googler behavior. :-)

Re: Android platform engineer on application architecture

#83
post #51

Rails is built on top of Ruby language, designed to be opinionated, following MVC. You like it, you use it. You don't like it, try another framework. Using the same analogy, Android is build on top of Java language, is 'opinionated': instead of designing with Model, View, Controller components, it's designed with 'unusual' components (as in not following any classic architectures) e.g. Activity, Service, ContentProvi…

> You like it, you use it. You don't like it, unfortunately you still have to use it.

You always have the option of falling back to OpenGL-rendered widgets and using a framework with MVC if you want to. Qt supports this, for instance.

Re: Android platform engineer on application architecture

#84

Earlier quoted context omitted.

> Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. Layout managers are complex technology now ? The layout managers Android uses are pretty much identical to what Java used in AWT and Swing and is trivial to implement. I know because I implemented just such a thing for a UI t…

What's wrong with intents now?

Intents don't work because they were designed to be too flexible.

Say I want to be able to share something on social media from my app, seems like the exact use-case Intents were made for. So I create an intent of type ACTION_SEND because that's the only one that sorta does what I need and now my user gets a HUGE list of options, half of which are irrelevant and/or don't work at all. I cannot limit the Intent to 'share on social media' because it has no such category. You cannot filter the list yourself because that would mean having to know the package name of every possible social media app.

Worse, even the well known social media apps do not work. No one agrees on what fields should mean what and how to interpret them. For example: you can create an intent that prefills the text and attaches a photo and it will work when you use it to open Twitter but not Facebook, facebook ignores the pre-filled text. Another app will ignore the photo, etc. you can't test every possible target app so the whole mechanism is unusable if you want to deliver a good UX. In the end you give up and just add the Facebook and Twitter SDK's to your app.

Another example: we have an app that deals with privacy-sensitive information. We want the user to be able to e-mail this to him/herself but nothing else. Or rather: we don't want our users to accidentally share this information on social media. You cannot create an Intent that will only open the users preferred email client and excludes everything else.

Intents are pretty much worthless if you care about a good UX at all.

Re: Android platform engineer on application architecture

#85

I remember her name. Wasn't she the one who vehemently was defending activity lifecycle and other broken multi-threaded API, something every Android developers I talked to would consider totally broken? To be fair, developing on Android has become so insane releases over releases that her crazy write up about no engineering design hardly comes as a surprise... Shame on Google for forcing us to use that POS.

I met her once at Google I/O, and it wasn't a pleasant interaction. I was lamenting how the recent (at the time) switch from USB Mass Storage to MTP made file transfers to and from computers very iffy. (And it's still pretty iffy today.) I was asking why the change was made, and if there was a chance at the option for it being restored, as devices used to allow both.

A lot of times, files on the Android device don't show up properly in Windows Explorer. She asked what I was doing, and I said copying APK files. (I regularly used to backup APKs so I could revert software updates which degraded the experience.)

She immediately stated that they "didn't support piracy" and walked off. As if the process of sideloading APKs or transferring them to and from a PC was somehow automatically illicit activity, rather than... something a lot of developers probably do regularly.

Re: Android platform engineer on application architecture

#86
post #3

Earlier quoted context omitted.

I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is. My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.

Do you mind expanding on some of your statements? Especially: > Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.

I work on a very popular app in Latin America. That means we get to experience every single edge case in the eco system. My favorite quirk has been that for some reason I will never understand when an app goes into a full screen ad it can make your main activity eligible for GC. That means that you don't get any of your Activity life cycle events. Just a lone finalize and your app is gone. Then when the video ad is done you get a truly spectacular crash!

Sadly, I have a half dozen different ways activities have found to explode themselves. It makes me sad!

Re: Android platform engineer on application architecture

#87
post #63

Earlier quoted context omitted.

Android is usually pointed to as a success story for Java performance. I thought that it was just us that had performance issues because we were developing a big app with a completely custom UI... Interesting to see that others feel this way. The conclusion is that it almost doesn't matter what language you choose for a platform if you have enough man-power and resources and you can force developers to use it. :)

Java performance on Android is crap. The real succes story for Java performance is on the server side.

where no one can actually see the horrible performance which would be immediately noticeable in any environment with UI interaction... think falling trees in a forest...

Re: Android platform engineer on application architecture

#88
Android noob here. I've been teaching myself Android programming for the past couple of months and I've found it overall a messy and unpleasant experience for the reasons many of you have already mentioned. So much, in fact, that I'm looking for alternatives.

So what's the best option?

Kivy? Python is slow, adoption seems non-existent, not suitable for every kind of app

Cordova? Web apps are slow, JavaScript sucks big time

Qt? Google discourages use of the NDK for developing apps, can't figure out anything from their crappy website

Xamarin? C# doesn't look like a significant step up from Java, from Microsoft

Delphi? Proprietary, Windows-only and costly

Clojure/Kotlin/Scala? It seems you need to be a master Android developer to use them, still doesn't get you out of the horrible Android architecture.

Re: Android platform engineer on application architecture

#89

Earlier quoted context omitted.

Because you don't need to know. Permissions are sacred. If you don't have the permission, consider the capabilities aren't there and move on. How would you feel if Facebook or Instagram app refused to start if you didn't give it camera permission? Maybe I don't have a working camera in my Nexus 6.

Unfortunately, this is what Google's own app for the upcoming Google I/O conference does if you deny it access to your contacts at startup. If you grant the permission only to deny it later, the app won't start again until you grant the permission again. https://play.google.com/store/apps/details?id=com.google.sam...

That sounds horrible. I can't see a reason why they'd do that. Can you think of anything why this behavior happens?

Re: Android platform engineer on application architecture

#90
post #11
post #3

Earlier quoted context omitted.

I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is. My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.

How would the ndk help, doesn't it run within an activity?

I use the NDK a lot because you can kind of ignore the Android nonsense and structure your code properly. My approach is to have it build out the main activity then fire out into my app code. That code is beautifully MVC and for the most part ignores Activities, Fragments and Intents. For me it was faster to develop in than Android Java because I wasn't so strongly tied to the view code.
Post reply on HN