Frequently asked questions

Should I use Proteus?

Proteus was written with dynamic layouts in mind. The primary use case being the ability to send XML layouts from the server. This ability is usually required if you want the server to decide the rendering logic for UI. Traditionally a WebView would solve this issue, but at the cost performance and user-experience. This is where Proteus comes in since you want to tweak the views from the server side, but the logic and handling of the views are still baked into the app.

Why not send XML over the wire?

As per Google documentation its current not possible for LayoutInflater to do this. Even if you go ahead and try it out, you will get a ClassCastException.

For performance reasons view inflation relies heavily on pre-processing of XML files that are done at build time. Therefore, it is not currently possible to use LayoutInflater with a XmlPullParser over a plain XML file at runtime; it only works with the XmlPullParser returned from a compiled resource (R.something file.)

What about the Java code?

Since Proteus just replaces LayoutInflater, you still have to write Java code as you usually do. The only difference being findViewById. For regular XMLs Android's AAPT will generate an R file containing all the IDs. For proteus, all you have to do is that call getUniqueViewId(<id as a string>) with the exact same ID as a string on the ProteusView returned by LayoutBuilder. Then pass this id to findViewById the usual way. This works because Proteus generates unique IDs which can later be referred through findViewById

But, won't the Java code break when new layouts are pushed from the server ?

Usually, the java code refers to views defined in XMLs only through View IDs. As long you do that, the only thing to keep in mind is to not change the IDs. This is a contract between the views and java code which you have to maintain.

Awesome, why not ReactNative?

Yes, react native can also be an alternative to this approach. But react native approaches this problem from a web developers point of view. We approach this problem from an android developer's point of view.

React native can substantially change the way you do android development. The APK size increase could also be an issue for you if you move to react.

Okay, what about performance?

The performance was one of the key element which was not compromised in Proteus. The current benchmarks show that it's pretty close to LayoutInflater. We are working on a new version which will improve performance significantly by pre-compiling JSON to a binary format. This should make it faster than the built in LayoutInflater

Why JSON, why not something else?

JSON is ubiquitously used by most apps. In the near future, the core of Proteus will not depend on any format. JSON will be one of the formats supported out of the box, and new formats can be plugged in easily.

Will there be scripting support?

No. Right now, scripting support is being evaluated with Mozilla Rhino. Data bindings and formatters should solve most use cases. If these do not meet your requirements, React-native looks like a perfect match.

Using Picasso or Glide for loading images

You can do so easily by setting a BitmapLoader on the LayoutBuilder and implementing the getBitmap() method.

BitmapLoader bitmapLoader = new BitmapLoader() {
  @Override
  public Future<Bitmap> getBitmap(String imageUrl, View view) {
    return null;
  }

  @Override
  public void getBitmap(String imageUrl, final ImageLoaderCallback callback, View view, JsonObject layout) {
    // use the `imageUrl` and `view` with Picasso or Glide
  }
};

layoutBuilder.setBitmapLoader(bitmapLoader);