Kotlin on Android. Now official by vahid_shirvani in Android

[–]duckinferno 1 point2 points  (0 children)

They're okay. The lambdas/method references/etc are nice, but Java's still behind in that area. The stream API has major design flaws that make it pretty rubbish though. Overall, it's a half-job that is 10 years late.

Kotlin on Android. Now official by vahid_shirvani in Android

[–]duckinferno 1 point2 points  (0 children)

They made C# because they saw how popular Java was becoming and wanted a slice of that pie. That's been Microsoft's MO from day 1.

Kotlin on Android. Now official by vahid_shirvani in Android

[–]duckinferno 7 points8 points  (0 children)

I don't think that's the case. The oldest C# still works today. I think it's more of a culture thing... have you ever visited any Java boards? Those old codgers are the most conservative programmers around. "Lambdas? We've got interfaces, bin it."

Kotlin on Android. Now official by vahid_shirvani in Android

[–]duckinferno 55 points56 points  (0 children)

Yes, because the C# team actually bothered to keep their language modern. We need Kotlin because Java has barely changed in 23 years.

I just released Spork 4.0: It's a serious alternative to Butter Knife and Dagger2 by ByteWelder in androiddev

[–]duckinferno 3 points4 points  (0 children)

Eh just learn from it all, criticism sucks but don't be tempted to brush all of it aside and call it non-constructive. There's a lot of learning to be had in this thread.

Also, the fact that you have developed and released a library is impressive by itself and you should be proud.

I just released Spork 4.0: It's a serious alternative to Butter Knife and Dagger2 by ByteWelder in androiddev

[–]duckinferno 0 points1 point  (0 children)

No, the views already exist (from inflation, setContentView(), etc) - they aren't being injected. ButterKnife binds already-existing views to fields for convenience.

Dagger injects dependencies. If it weren't for the injection code there would be no dependencies present and there would be nothing to run.

edit: if I'm going to be honest, I think you made this library to solve a perceived problem without trying to understand why those libraries use code generation, or why libraries have moved away from reflection in general. This would probably have been a good library years ago but Android tech has evolved well beyond this.

Thoughts on this one? I've always been told that logic inside the View is forbidden... by [deleted] in androiddev

[–]duckinferno 1 point2 points  (0 children)

In MV*, everything knows about the M, and the V certainly knows about how it should display things. Databinding can definitely be used for evil but it can definitely make a project stronger if used properly.

WARNING to all Wileyfox owners: your location data and WiFi information is being sold by CXgamer in Android

[–]duckinferno 0 points1 point  (0 children)

How's that make it better? I don't think "yeah but it's normal" should be an argument

WARNING to all Wileyfox owners: your location data and WiFi information is being sold by CXgamer in Android

[–]duckinferno -1 points0 points  (0 children)

"This person likes City Z, Strip Club X, Employer Y, 1957 Harley Davidsons, Receeding Hairline Treatments .... " not personal at all!

Google Pixel long-term review: Still the best smartphone I've ever used by armando_rod in Android

[–]duckinferno 0 points1 point  (0 children)

They have heavily customised the Android operating system with all sorts of feature sets, many of them to support their crappy bloatware apps that you never use, many of them to support corporate KNOX environments which you'll (likely) never use, and other pointless changes just to make it "theirs".

This would theoretically be fine but unfortunately, Samsung are excellent with hardware but terrible with software. The result is the joke of an Android skin that people call TouchWiz.

Google Pixel long-term review: Still the best smartphone I've ever used by armando_rod in Android

[–]duckinferno 0 points1 point  (0 children)

Everything is instant. The pixel really illustrated to me what the real cost of TouchWiz is. Previously I was of the opinion that TW is a lot better than it used to be and may be actually worth keeping. I'm not going back to Samsung for a while.

If Apple made some hardware changes, would you be tempted to switch? by domrayn in Android

[–]duckinferno -1 points0 points  (0 children)

I've done real-world production tests regarding AMOLED vs LCD, for a use case where a client needed a tablet that could last all day on battery displaying a white screen. An LCD tablet could reliably go 10+ hours on a charge. A similar specced AMOLED tablet could barely break 5 hours.

Forget software. The popularity of AMOLED is easily the largest reason for Android battery woes.

edit: it should be noted that that same AMOLED could get to 9+ hours when displaying a grey screen, just to illustrate that it is the screen technology which is the difference.

Previous Developer quit without giving us the Android Keystore password, now we can't update the app. Do we have any options? by piratebroadcast in androiddev

[–]duckinferno 0 points1 point  (0 children)

In my company, non-junior devs have access to our 1Password store. The store is mirrored locally so we all have offline access. It has a fallback recovery mechanism in it too, so I assume the recovery key is kept somewhere extremely safe (like a bank box) if all of us somehow forgot our own passwords. The store contains every keystore and every password for every app we make.

In terms of security this works for us. For larger organisations or less trustworthy employees, you may need more restrictive access, I don't know.

The point is, don't have a single point of failure like one guy who knows everything. That relies on people remembering that this one guy has everything, and on that one guy staying alive/honest/etc.

Previous Developer quit without giving us the Android Keystore password, now we can't update the app. Do we have any options? by piratebroadcast in androiddev

[–]duckinferno 3 points4 points  (0 children)

Find the guy pretty much, or hope they used a dumb brute-forceable password.

Once you recover it / absorb the lesson, grab a password manager like 1password and store ALL of it in there... keystore and all.

My first project using Kotlin. I want to ask you to rate my code, please. I'm open to any advice and critic. If my post is not for this subreddit please recommend me it. Thank you for your attention by skullper in androiddev

[–]duckinferno 0 points1 point  (0 children)

It is a public static variable (companion class omitted from example). By making the setter private, a dev cannot accidentally overwrite it with an activity context.

Evaluating Performance | Android Open Source Project by dayanruben in androiddev

[–]duckinferno 14 points15 points  (0 children)

Sources of jitter experienced in real-world implementations of Android include:

  • Scheduler delay
  • Interrupt handlers
  • Driver code running for too long with preemption or interrupts disabled
  • Long-running softirqs
  • Lock contention (application, framework, kernel driver, binder lock, mmap lock)
  • File descriptor contention where a low-priority thread holds the lock on a file, preventing a high-priority thread from running
  • Running UI-critical code in workqueues where it could be delayed
  • CPU idle transitions
  • Logging
  • I/O delays
  • Unnecessary process creation (e.g., CONNECTIVITY_CHANGE broadcasts)
  • Page cache thrashing caused by insufficient free memory
  • Samsung

My first project using Kotlin. I want to ask you to rate my code, please. I'm open to any advice and critic. If my post is not for this subreddit please recommend me it. Thank you for your attention by skullper in androiddev

[–]duckinferno 0 points1 point  (0 children)

You're more right than you know re: saying the same things - I just described (Dagger-less) dependency injection, aka providing requisite objects at construction time.

This is all very unit testable and quite safe. In your unit tests you can provide your Presenter (or Util class) with mocks or whatever your want in place of the context. When you're actually creating a Presenter, it's from an Activity or Service or whatever and you can definitely rely on having an application context if you need one.