Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Doctor w-rw-rw-
Jun 24, 2008

Literally Elvis posted:

I am new-ish to programming, and you were totally right. By using Java's debugger, do you mean jdb or things like breakpoints in Android Studio?

I'm unsure if my use of Log.d() is appropriate or not. I've been using it the way I've used it above because it's helpful to see the filtered output in logcat for diagnosing various problems (though this didn't help, and presumably breakpoints would have). Should I be using them more frequently/sparingly?

I meant the IDE's debugger, such as the one in Android Studio, yes. GUIs shouldn't be taboo if they help you use powerful tools better (but if you are uncommon and text is your thing, and you're more productive that way, all power to you). As for whether your use of Log.d(), sure - use whatever tool you can to track down problems. If logging is confusing you on a bug, then try a different approach. Debugging is hard to get good at, but the first step is recognizing where it can help, and you've already spotted a good example.

Another thing that might help is using a good color scheme that is not only easy on your eyes (i.e. a dark gray or black background instead of white), but which has good contrast in its colors, so you can figure out that you're setting a local variable instead of an instance variable by inspection by looking at the color of the variable.

Really, any additional signal you can add to finding problems that doesn't increase the noise by too much is probably worth considering. For example, religiously autoformatting your source code so that code lines up consistently might help, too, or naming variables consistently (i.e. always declare a FooBarController as FooBarController fooBarController unless you have reason not to) helps you spend your brain worrying about problems that actually matter.

Adbot
ADBOT LOVES YOU

Doctor w-rw-rw-
Jun 24, 2008

Newf posted:

... the character building kind of pain?
That or you slowly go insane until you have a nervous breakdown and set your career back a couple years. Hi there!

Newf posted:

Yeah, I'm pretty competent in Java and .Net/C#. Haven't touched Objective C at all, but hell, it's just another modern C style language?
Objective-C has more in common with Java than C, but also has its fair share of idiosyncrasies. As a language, it's not hard to get used to. The APIs are always - in my experience - the most important thing to adapt to. Languages are easy. Luckily, iOS APIs are pretty decent. If you can handle Android, you can handle iOS for sure.

Newf posted:

Uh, ($120 in licenses, $600 for a Mac mini, $5000 for me) x 3 = $17160. That seems utterly insane to me, and I'll probably pitch something closer to 5k? That would keep me from starving to death!
$20k sounds pretty reasonable but definitely charge hourly because you will either produce crap, you will fail, or you'll put in so much time making it work that you'll earn that sum and more. Expect unexpected challenges.

Doctor w-rw-rw-
Jun 24, 2008
Saw a friend post this: https (friend of friend is author) http://github.com/facebook/proguard

Apparently, it's 2.5x faster than upstream proguard, or so they claim.

Doctor w-rw-rw-
Jun 24, 2008

scanlonman posted:

Is there a guide for how to architect an Android application? I've seen people have one activity that controls many fragments, one activity for each fragment, and probably variations of both. What is the "right" behavior? How do fragments communicate with each other?

I can't find one set answer on what to do. Sadly Android doesn't easily conform to MVC :smith:
I've done variations on both ways to do it and more, and there's no totally right answer.

For fragment communication, the way that is "anointed" is to pass interfaces around between fragments. Problem with that is that you've adopted the overhead of maintaining an interface from the outset, possibly before you even know what you're building. So I used to use (it's been a loooong time since I did Android) a weak reference to the owning activity instead, and call methods as necessary.

Other tips -
* Don't stack fragments if fragment state is important. Back-stack state restoration is unreliable (did they ever fix this?)
* When creating and launching a new activity, it's pretty convenient to stick the info you used to launch the activity in the intent. It's immutable and if your activity's state gets reset, it still has access to the intent used to make it and can reconstruct its original state pretty easily.
* If you're dealing with video views inside fragments, HERE BE DRAGONS. Video views have a lifecycle of their own. Dealing with activity and fragment lifecycles on top of that is scary.

Doctor w-rw-rw-
Jun 24, 2008

Safe and Secure! posted:

So what's the state of android development tools? Is everything still the biggest pain in the rear end possible? I want to play around with android but I dread spending a day to get a hello world app running on my phone because I have to download a special version of eclipse and then make sure I've got a billion different plugins installed and configured properly.

I say this despite liking and preferring Eclipse over IntelliJ - just use Android Studio.

Doctor w-rw-rw-
Jun 24, 2008

Yesssss...let the hate flow through you. I went through nearly the same thing a couple of years ago, though possibly worse since Android 7-9 was a total shitshow and video playback was the wild west on any Android version less than 4.0, and still woefully inconsistent and terrible on higher versions.

Thanks for the article.

Doctor w-rw-rw-
Jun 24, 2008

speng31b posted:

My favorites are crash reports from embedded html5 video trying to play in a webview.
Definitely preferable over one or more video players inside a fragment each, inside an activity, though.

Doctor w-rw-rw-
Jun 24, 2008

Subjunctive posted:

Hi all!

I'm putting together an inventory of common (or even not-so-common) Android application security issues. Things like mishandling intent/activity activation, putting private stuff in logcat, data-at-rest vulnerabilities and so forth. I've found a couple of decent resources, such as the AppSec pen test overview (https://appsec-labs.com/android_attacks-tests/) but I thought I'd ask if people had other good places to look.

(Related: I'm hiring Android systems/app security expertise.)

Not sure how relevant it is, but I just remembered one particularly hilarious Android exploit for devices using Samsung's Exynos chipset: /dev/exynos-mem was readable and world-writable which referenced – you guessed it – device memory.

In case you don't already have it in your list of attacks, here's more info on that vulnerability: http://blog.azimuthsecurity.com/2013/02/re-visiting-exynos-memory-mapping-bug.html

Doctor w-rw-rw-
Jun 24, 2008
My understanding jives with yours that RSA isn't intended to be used as a block cipher and ECB sucks. I haven't used them together, although my slightly-informed guess would also be that it doesn't matter because ECB is ignored.

Given that Android uses a cut-down BouncyCastle for its crypto (link), I'd say that if you've looked at BouncyCastle and found that it ignored the operation mode, chances are very good you'll see the same behavior on the standard Android platform

Doctor w-rw-rw-
Jun 24, 2008

Subjunctive posted:

Why is that? I came across something else that said that recently, but didn't say what problem it avoided. I'm just getting back into Android development, so these sorts of gathered lore are interesting to me.
Same reason it'd be weird to put classes, interfaces, and enums each in different packages – your taxonomy should be concerned with organizing major functionality, experiences, or some other sort of meaningful separation. (Opinion)

If you categorize by activities, exploring cross-package dependencies as a heuristic to grok code one major piece of functionality at a time suddenly becomes a lot less consistently useful or predictable.

Doctor w-rw-rw-
Jun 24, 2008

speng31b posted:

If you're talking about writing your own BLE utility, I'd suggest you run fast in the opposite direction. I can go into more detail if you want, but for now I'll just say Android BLE support is -bad-. I'll do the whole rant if anyone's interested.

Please do.

Doctor w-rw-rw-
Jun 24, 2008
*Flashes back to Android 2.x VideoView pain*

Good stuff. By which I mean, that totally sucks, and sounds like typical Android. Sorry man.

Doctor w-rw-rw-
Jun 24, 2008
http://verybadalloc.com/android/2015/12/19/special-place-for-samsung-in-android-hell/

Ah, Samsung. Such a familiar feeling of disappointment.

Doctor w-rw-rw-
Jun 24, 2008
https://source.android.com/devices/tech/admin/provision.html

Doctor w-rw-rw-
Jun 24, 2008

Volmarias posted:

You are. I'm suggesting publishing (:airquote: "publishing" :airquote:) the data to a singleton that the activity can query, and which listens for broadcast intents. Otherwise, yeah, add/remove a listener as part of the life cycle of something but don't just straight up jam an activity in there.

I preferred app-scoped or some-notion-of-session-scoped properties on a class, and calling that a Manager, Coordinator, or Controller (i.e. "FooManager", "FooCoordinator", or "FooController"), or maybe Listener or Announcer, depending on the specific thing it's doing. The broadcast intents method seems not unreasonable.

Adbot
ADBOT LOVES YOU

Doctor w-rw-rw-
Jun 24, 2008
https://techcrunch.com/2017/04/18/facebook-expands-its-open-source-portfolio-with-new-ui-framework-for-android/
Essentially ComponentKit for Android, and ComponentKit is essentially React* for iOS.

* The pattern – React is both a pattern and an implementation, but this fact gets often overlooked because React is so strongly associated with React.js.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply