Shai Almog

+ Follow
since Jun 25, 2014
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Shai Almog

No. We use Spring Boot for the backend and Codename One for the front end.
3 years ago
IntelliJ is a great IDE. Android Studio removed a few things needed by Codename One to compile. It's also really slow... Painfully slow. There are tips to make it "bearable" but a vanilla install of IntelliJ still runs circles around it.
We don't need any of the features in Android Studio unless we want to debug the native Android code (which I don't cover in the book and frankly rarely do as it's redundant).

Providing hints for people moving from Android makes a lot of sense. We made several attempts at doing that but things change on the Android side quite a lot and it's hard to keep up (things also change in Codename One so it's a two way street of problems).
3 years ago
Thank you all!
Great questions so far, keep them coming.
3 years ago
I agree analytics and growth is a very important subject. I skipped it in the book as it covers building the app and not bringing it to production. The basis of analytics is very simple e.g. just add API X. But that's the first 1% of the story. Understanding analytics results and iterative improvement (via among other things: A/B testing) is 99% of the work here. I think these are best explained via real world app growth stories.

From my experience with app developers I think a lot of us tend to put more weight on analytics and these tools than on marketing. Sure, we need a stable intuitive app but whether the signup button is Orange or Red is often within the margin of error. Successful apps solve an important problem and have great marketing. Both of those things are very specific to your app.

The book does cover security although it isn't a security book. I discuss several potential flaws mostly on the sever side as I deal with them. The final app has potential security issues which I highlight in the book. I coded it this way as it made more sense as an educational tool. All of these issues have easy fixes explained in the book.

I discuss some performance issues but it's mostly irrelevant. The Uber app is very simple for the most part and performance isn't a challenge. I have a future book chapter written about performance which I might package into a different book. Performance is a hard thing to cover in a book as it's such as fluid subject. There's the tooling the common pitfalls and case studies. It's hard reading and doesn't really fit into this book format.
3 years ago
I have no knowledge of how Uber is actually implemented and didn't seek that out. I wanted to keep things "clean".
From my experience with such companies/projects I'm pretty sure the code is huge/old and filled with patches. It's really hard to migrate apps like this to any sort of new tool/technology/language. A rewrite is always tempting but it's often a huge task that managers try to avoid.
3 years ago
Codename One has a JavaScript port that builds a web runnable version of your app seamlessly. The Bluetooth support in Codename One isn't as great as some other features because it's a port of a Cordova library. If there was more demand we could have made something more powerful that leverages the advantages of threads etc.
3 years ago
The entire clone fits within the free quota of Codename One with room to spare. Furthermore, the free build quota can be increased see:

I think you can gain insight into general full stack development that are universal but the book is very pragmatic. It focuses a lot on the "details" which are to a large extent Codename One specific.
3 years ago
I discussed both of these in other questions here. Reviewers actually read the whole book over a weekend. Obviously this assumes a relatively experienced engineer that can digest information quickly.
I created the original Uber clone on which the book is based in roughly 7 days, obviously I have a bit of experience but it is very doable. Notice that I reference "startup days" which are longer than a typical day.

I don't use TDD in the book as it's already pretty big and as you said, stretches the meaning of "DAY". I'm a big believer in TDD which is why I think it should get a treatment of its own.
3 years ago
If you used Swing for the desktop app then Codename One should be very familiar to you.
Codename One is a native framework, that means you can use native tools and 3rd party libraries. Any JavaScript framework eventually runs into the limits inherent in the platform:

- No access to native unless you go to a separate activity
- Single threaded coding - for better/worse
- Fragmentation of the JavaScript implementation on devices

I think the best thing to do is try the different options in a simple test case and see what works for you.
3 years ago
The tools are pretty different. Here are a few high level differences:

- Codename One uses Java or Kotlin. React Native uses JavaScript
- Codename One compiles to native. React Native calls native code from JavaScript
- Codename One's development process works in a Java IDE where you use the Codename One simulator. You can then build a native app without the native SDK or hardware. E.g. you can build an iOS app without a Mac. React native uses the native SDK's for development
- Codename One is a Write Once Run Anywhere framework with one code for everything. React Native is opposed to that
- Codename One uses lightweight architecture. React native works with system widgets only

The last point is core to everything that's Codename One. It means Codename One draws almost all of the widgets. This allows 100% portability as the code is Java, so what you see in the simulator works on the device. It allows you to just override paint and draw whatever you want. You can control every pixel on the screen... Like Swing or JavaFX. But here's the cool part... Heavyweight mixing.

To write an app like Uber you need Google Maps. That's a native OS widget, it's implemented as a native widget but the cars on top are Codename One Components that draw on top of it. AFAIK Codename One is the only mobile framework that allows that.
3 years ago
If I'd ship an app with Uber branding it would be a copyright infringement. This is an instructional tool that relies on fair use.
The app doesn't use branded materials other than the logo, everything was created from scratch.
3 years ago
FYI this is exactly what my book covers:
It's literally the subtitle of the book.
3 years ago
I looked again at this after answering and I think this segment from the preface of the book fits here:

Last year we launched the Codename One Academy. As part of that offering we surveyed the Codename One community and asked them: "what would you like to learn?".

The response was was overwhelmingly: "How to build an app like Uber!".

At first I thought about creating something in the style of Uber but I eventually settled on building something that looks really close to the native app. Almost a clone.

My motivation for going for a clone instead of coming up with a completely new design was driven by this line of thinking:

* I wanted the design to look professional and you can’t go wrong with a design from a top tier vendor

* People can learn a lot by understanding the decisions Uber made — I know I did

* If I would have built something different I might have given myself “discounts” that don’t exist in the real world

I used the word clone to indicate the similarity but not to indicate a carbon copy. Uber is a huge and nuanced app and I had only one week to write all the relevant applicable code.

My goal was to do the "hard stuff" and gloss over some of the deeper details. The goal is to teach with a strong focus on the mobile side. I wanted to create a book that would show you how to build a fully functional MVP (Minimum Viable Product) within a week. I wanted to illustrate the shortcuts that make sense and those that don't. This is a powerful approach whether you are building a startup or working within a large corporation.

I think developers can't deliver truly innovative ideas if we are constantly doing the same app over and over. By making this process simpler I hope that developers will adopt innovative ideas faster rather than re-do the same apps all over again.
3 years ago
It's literally a working clone of Uber including the UI and basic functionality such as SMS based activation, maps with cars on them, driver accept process, separate driver app (although that's not as refined) etc.

The goal is teaching so it's not something you can take and use as is to sell to a customer. But the distance to a usable beta wouldn't be huge. That obviously depends on the type of the application.
3 years ago
No. The book uses Codename One which has different abstractions for network. E.g. to invoke a Rest request on the server one would do something like this:

I don't like using annotations and injection for mobile code. The problem with those is two fold:

- They can't be verified by the compiler so you end up with errors in runtime for complex conditions
- Obfuscation usually fails in these cases so you need complex proguard logic

Instead we use a different technique specifically designed to withstand obfuscation while keeping the runtime much smaller. It's nice when an Android app compiles to a 3mb APK instead of 5mb. But when we compile that code to iOS the difference is 15 fold!
3 years ago