unsoundInput
At least two core products of the biggest advertisement company in the world have no problem providing you value and generating ad-revenue without you having to be logged in. Google and YouTube would be nowhere near the success they are if they'd force you to log in.
I honestly believe that could do much better by providing a good experience to people that just want to stay up-to-date and follow a few people that they find interesting.
The most problematic performance issues I've come across were usually bad/premature optimizations that were not (correctly) validated against a simpler implementation as a performance baseline. Things like parallelism (multi-threading, web workers) or caching can absolutely tank performance if not done correctly. Plus they usually tend to make stuff more complex and bug-prone.
The code for the binding classes lives in retrofit.adapter.{guava|rxjava|…} [0] but the respective library still lives in its usual package. [1]
If that weren't the case you could A) not manually provide a minor version via your dependencies block in your build script and B) would have interop problems between libraries and between a library and your code as the same interface copied to a different packages is not the same interface for Java.
[0] https://github.com/square/retrofit/tree/master/retrofit-adap...
[1] https://github.com/square/retrofit/blob/master/retrofit-adap...
The problem - from what I understand - is that you used to be able to use the systems sqlite.so to access databases owned by your app from the native environment. With Android N you are no longer able to do this, you need to ship your own sqlite binary.
This can lead to problems when you want to access the same sqlite files from both the Android platform APIs and native (e.g. use it from native for business logic, debug it with a tool like Stetho [0] that uses android.database.sqlite) because of a version mismatch.
Would Google offer (a copy of) the Android API with the ability to plug in a different sqlite-compatible binaries, it would very likely find broad adoption. Then the problem stated by the article could be solved by shipping the app with a sqlite build that is used by both the native code and plugged into the compat library.
There are already implementations [1][2] of this, but because it is not provided by the Android team it is hardly supported by ORMs, libraries, etc.
[0] https://code.google.com/p/android/issues/detail?id=202658
With that in place it is questionable what the actual advantage of semver vs a simpler monotonous versioning schema (like build number or UTC date) is.
A) avoid breaking API changes
B) if you have to do large breaking API changes, that will probably affect alot of dependent projects, make it a new artifact / namespace / library that can live side-by-side with the old version
B is actually pretty common in large java library projects (rxjava -> rxjava 2, retrofit -> retrofit 2, dagger -> dagger ‡ all have independent maven artifacts and I think also packages) and imho this approach makes a lot of sense. It's also the more important part of this talk compared to his critique of semver.
Is it Ember/Vue-style "mutate, observe, compute" as implied by most of their example code or Flux-style as implied by their introduction visualization (https://github.com/mobxjs/mobx/raw/6ed404b96a8b4074a473accd2...)? Do I create actions or just mutate state directly (again, visualization and some text in the readme vs examples)? How is "observer turns React (function) components into derivations of the data they render." any different from just plain React components?
MobX feels like someone tried to make an easy state management solution (obviously a great goal) and in the process just threw together whatever pattern exist out there right now. It obviously works for many people, considering how often someone comments about it on HN, but I wonder what makes those user stick with React vs a framework that completely embraces this approach like Vue or Ember.
Is it some hard requirement on React?(EDIT: Or maybe preference of JSX?)
The value for FP comes from proper abstraction over these processes in functional terms, at which point they can be trivially implemented (few bugs, few iteration cycles to get right). This can probably be done for every problem space, question is at which the abstraction costs outweight the gain. Considering that FP becomes more and more mainstream it's probably more viable than thought in the past, still I imagine system-driven games or complex real-world simulations, with lots of side effects, would lose more from FP than they'd gain.
In a usecase where you consider independent databases, with few interactions between them, for millions of users (and a few MBs + binary blobs of data per user) I'd certainly consider it as a possible solution.
EDIT: Well, looks like someone beat me to it
I don't see a simple, low on boilerplate, one-size-fits-all solution for reusable and separated components on Android at the moment. I love that the community didn't settle with just Activities or just Fragments and is actively trying new stuff (after all, if you look at React or Vue or even freaking backbone.marionette, the web is in a much better spot right now regarding UI composition), but right now the right solutions always seems to take the path of least resistance and use whatever mix of pattern that gets you to your goal as easily as possible.
The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments when you need them, stick to Activities if you can) that is state of the art in Android development. I think it's a great thing to skim through if you are interested in developing for Android or to compare it to you own app.
I can only assume that the same is true for I iOS. I'll certainly check it out should I start developing for that platform.
<template>
<div>
<h2 class="c-section-heading">HELLO</h2>
<p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
<p v-if="location.query.home">You specified a home query: {{location.query.home}}</p>
<a v-else v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
</div>
</template>
<template>
<div>
<h2 class="c-section-heading">HELLO</h2>
<p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
<p>You specified a home query: {{location.query.home}}</p>
<a v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
</div>
</template>
Compare this to the other react solutions, or my personal favorite:
const Home = ({location}) => <div>
<h2 className="c-section-heading">HELLO</h2>
<p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
{location.query.home
? <p>You specified a home query: {location.query.home}</p>
: <a onClick={specifyHomeQuery} className="u-warn">No home query was specified.</a>}
</div>
The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.
Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.
In a React render() function I would just use
filter( (it) => { //some predicate } )
map((it) => { switch (it.contentType) { // cases } })
To me it looks like to implement something like this in Riot would require to build / use something that is more like Angular's computed properties.
But I'd like to be proven wrong.
Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.