fix(Android): Present the component immediately if there's only one

[tido64]

[arazabishov]

Hmm, you will lose access to the dev menu options on start. Also, backstack behaviour will be somewhat unintuitive where it gets you back to a screen that you haven't seen when launching the app.

It makes a lot of sense on desktop where you land to a component on start and always have access to contextual menus. If we want to make it "cleaner" on mobile I would suggest to make dev menu somehow accessible everywhere and do not allow to go back to the list of components.

[tido64]

If we want to make it "cleaner" on mobile I would suggest to make dev menu somehow accessible everywhere and do not allow to go back to the list of components.

I tried replacing the Activity as soon as I am able to detect that we only have one component. The issue I hit next was that we'd always load the bundle from disk, so I turned it on as long as it is a debug build. I think the shaker menu is enough for most use cases. The context menu we provide is mostly for convenience. What do you think?

diff --git a/android/app/src/main/java/com/sample/MainActivity.kt b/android/app/src/main/java/com/sample/MainActivity.kt
index 52d2215..9ed7004 100644
--- a/android/app/src/main/java/com/sample/MainActivity.kt
+++ b/android/app/src/main/java/com/sample/MainActivity.kt
@@ -1,5 +1,6 @@
 package com.sample

+import android.content.Intent
 import android.os.Bundle
 import android.view.LayoutInflater
 import android.widget.TextView
@@ -56,12 +57,19 @@ class MainActivity : ReactActivity() {
         val manifest = manifestProvider.manifest
             ?: throw IllegalStateException("app.json is not provided or TestApp is misconfigured")

-        setupToolbar(manifest.displayName)
-        setupRecyclerView(manifest.components)
-
         if (manifest.components.count() == 1) {
-            startComponentActivity(createComponentViewModel(manifest.components[0]))
+            val component = createComponentViewModel(manifest.components[0])
+            startActivity(ComponentActivity.newIntent(
+                this, component.name, component.displayName, component.initialProperties
+            ).apply {
+                flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_TASK_ON_HOME
+            })
+            finish()
+            return
         }
+
+        setupToolbar(manifest.displayName)
+        setupRecyclerView(manifest.components)
     }

     private fun setupToolbar(displayName: String) {
diff --git a/android/app/src/main/java/com/sample/react/TestAppReactNativeHost.kt b/android/app/src/main/java/com/sample/react/TestAppReactNativeHost.kt
index 10d2523..df7728f 100644
--- a/android/app/src/main/java/com/sample/react/TestAppReactNativeHost.kt
+++ b/android/app/src/main/java/com/sample/react/TestAppReactNativeHost.kt
@@ -10,6 +10,7 @@ import com.facebook.react.bridge.ReactMarker
 import com.facebook.react.bridge.ReactMarkerConstants
 import com.facebook.react.common.LifecycleState
 import com.facebook.soloader.SoLoader
+import com.sample.BuildConfig
 import javax.inject.Inject
 import javax.inject.Singleton

@@ -39,12 +40,12 @@ class TestAppReactNativeHost @Inject constructor(
     application: Application,
     private val reactBundleNameProvider: ReactBundleNameProvider
 ) : ReactNativeHost(application) {
-    var source: BundleSource = reactBundleNameProvider.bundleName
-        ?.let { BundleSource.Disk } ?: BundleSource.Server
+    var source: BundleSource = BuildConfig.DEBUG
+        .let { BundleSource.Server } ?: BundleSource.Disk

     fun reload(activity: Activity, newSource: BundleSource) {
         assert(hasInstance()) {

[arazabishov]

The issue I hit next was that we'd always load the bundle from disk, so I turned it on as long as it is a debug build.
Ah, I see. I would rather keep the initial implementation then.

Do you think it will make sense to implement a different navigation pattern where having a default component feels natural? Something like a right hand side sliding drawer? For example:

Obviously, this will require more work and thought. We can get the PR in as the first implementation, but I would like us to think of other solutions too. @sweggersen any input on this?

[sweggersen]

I personally think that BuildConfig.DEBUG is not the correct flag to spot intent, since basically all builds you try in AS will be DEBUG.

I've had bad experiences when the app tries to be smart and loads the bundle from disk if available. I have to click load from dev server every time.
Can we do something like this:

Remember choice can be overridden later in a simple settings activity.

[arazabishov]

@sweggersen How would you access the settings screen when working with a single experience only?

[sweggersen]

Right. My diagram is a bit off on that part. I thought we would launch the single experience Activity automatically, but still launch the experience list first, so that when you exit the experience, you would go back to the experience list where we have control of the toolbar menu, and have it there.

[tido64]

On iOS, RN checks if the dev server is running first, then load the embedded bundle as fallback. I think we should implement (and upstream?) that feature. As @sweggersen experienced, I think it's wrong that it tries the embedded bundle first. As our users are developers, it's more likely that they want the dev server most of the time. I've created the issue here: #115. Let's revisit this after it is resolved.

[tido64]

Do you think it will make sense to implement a different navigation pattern where having a default component feels natural?

@arazabishov: Can we simply keep the current toolbar? We only have a few menu items, I'm not sure we need a whole right panel. In any case, it would be nice to get this in first and create a separate issue for it.

[tido64]

Opened #117

[tido64]

🎉 This PR is included in version 0.1.9 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀