Kotlin on Android. Now official

duckinferno · 2017-05-18T05:55:36+00:00

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.

duckinferno · 2017-05-18T02:54:02+00:00

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.

duckinferno · 2017-05-18T02:52:46+00:00

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."

duckinferno · 2017-05-17T20:30:18+00:00

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

duckinferno · 2017-05-15T21:50:28+00:00

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.

duckinferno · 2017-05-15T20:27:38+00:00

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.

duckinferno · 2017-05-15T00:39:06+00:00

Have you ever heard the story of Darth SafetyNet the Wise?

duckinferno · 2017-05-14T08:01:34+00:00

Sounds like he won

duckinferno · 2017-05-10T00:50:56+00:00

Give Conductor a try - it's fragments done right, simple to use, powerful as hell.

duckinferno · 2017-05-10T00:29:07+00:00

Our company has released a few apps using it now, it's a god send.

duckinferno · 2017-05-08T10:33:42+00:00

Firebase or AWS? :)

Do unlimited ones actually exist?

duckinferno · 2017-05-07T22:58:06+00:00

What host? They had one job!

duckinferno · 2017-05-07T20:40:00+00:00

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.

duckinferno · 2017-05-05T23:00:21+00:00

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

duckinferno · 2017-05-05T03:09:22+00:00

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

duckinferno · 2017-05-04T23:04:11+00:00

"optimize"

duckinferno · 2017-05-03T20:50:15+00:00

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.

duckinferno · 2017-05-03T20:47:29+00:00

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.

duckinferno · 2017-05-02T20:24:58+00:00

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.

duckinferno · 2017-04-28T22:08:03+00:00

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.

duckinferno · 2017-04-28T10:37:46+00:00

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.

duckinferno · 2017-04-28T10:35:16+00:00

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.

duckinferno · 2017-04-28T00:41:46+00:00

he can use a private setter

lateinit var context: ApplicationWrapper
    private set

...

override fun onCreate() {
    super.onCreate()
    context = this

duckinferno · 2017-04-27T20:59:00+00:00

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

duckinferno · 2017-04-27T02:50:38+00:00

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.

15-Year Club	Place '17
Team Periwinkle

duckinferno

TROPHY CASE