someUserTonight

I think the parent comment was saying that you could always make that explicit.

> By setting the value as null initially I can easily check whether the variable has been filled or not

I don't think there's anything wrong with this but it does mean your variable can be in two states~, one where "it shows it should be filled" and one where the value is present and can be used.

You can use null for this if you want and most programmers will understand these states. You can also choose to make this even more explicit by creating a type that expresses this.

example in Kotlin but you get the idea (applies to any variable in any language)

    sealed class ThatVariableYouCareAbout {
     object ShouldBeFilled: ThatVariableYouCareAbout()
     data class HasBeenFilled(val x: String): ThatVariableYouCareAbout()
    }

    // usage
    fun test(thatVar: ThatVariableYouCareAbout) {
      if(thatVar is ShouldBeFilled) {
         //
      } else if(thatVar is HasBeenFilled) {

      }
    }

Seems overly verbose but that's the reality of the variable you're talking about. This represents those states you described. `null` is a crutch in most languages for representing this state and the cause of a lot of subtle bugs (people use it to reset/clear out values too which in reality could represent a different state depending on what you _really_ want the variable to represent).

All that being said, null is generally understood to have this meaning~ and I have/do use it but with an understanding that it's of lazyness/not wanting to be overly verbose (language consideration).

The case you are describing is very familiar to me (rendering UI with initial states through a framework like react) and having an explicit type for the initial state is the ideal, or at least the most explicit, solution.

Option works for 2-state variables like this

Definitely possible. You can refactor your Android app to be split up into essentially two "modules", one with your business logic and then the UI/native platform specific libraries.

Once you have that setup you can then add a different platform "web/iOS". The base module would have setup certain contracts that new "platforms" would have to implement.

I wouldn't be too worried. I mean I think it's possible but I feel like it's a while away.

As a native Android dev, my arm-chair hypothesis is that currently both of those (kotlin, flutter) are targeting different developers and until either one starts including the other developers then I don't see any one winning over.

Kotlin - loved by native devs Flutter/Dart - web devs (previous experience with JS)

*I'm biased as a Native android dev but from my experience this is the case. Also Kotlin is really a great/fun(ctional)/expressive language

You share as much code as you want in the shared/base project and are able to create "contracts" for each UI platform that are enforced by the compiler.

If you're business logic needs these platform specific functionalities (which will definitely be the case as you've stated) then you can abstract out interfaces and let each platform handle them natively.

I think so. If we're talking about "out of the box" or what you'd find on average. As an Android dev for a few years now I think we get a lot out of the box and I get that web devs also use libraries or frameworks that have similar benefits. At that point it's comparing framework A's a11y vs framework B's a11y vs Android a11y.

Not an Android fanboy but I'm going to assume that the bigger (widely used/constantly iterating) "platform" (for a lack of a better term) has better a11y. And if there is a web framework that provides this (react?) do the majority of websites use it ? like they do native api's for native apps

(and this isn't even talking about the api's accessible to native vs web app)