Kotlin for Android

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Kotlin for Android

DiamonBack: May 7, 2019

Good day to all,
I am new to post in forum but i follow a lot of the topics in here, for that i am sorry if this is not the ideal place to post this topic

Today i thought i could create a post about computer language, more precisely Kotlin (Java for android).
I intent to talk about myself a little bit and at the same time get some opinions about this topic.

So this is the main topic i would like to see developed:
What you guys think of Kotlin and is it good to invest in learning this language? Is it better or more intelligent to bet on Flutter toolkit or Xamarin (.Net and C#)? How can one know what is the best investment?

As time passes by as a full stack developer i felt the need to follow along to android development and i started to do some flutter tutorials. After some time a colleague of mine told me that it is better to focus on some specific like full android or full iOS. In my head it makes sense, it is better to be good at one think rather that medium at several .. that made me change my focus to kotlin. although i still feel that i do not know enough of this world (mobile one) to make a final decision and that is where i hope to get with this topic.

With that said, could you help me in this quest?
Thanks in advance and cheers. o7

# ? Sep 23, 2019 17:56

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 23:38

CPColin: Sep 9, 2003; Big ol' smile.

I use Kotlin for building Spring Boot web applications and I've found it to be pretty good for that purpose. It helps that the Spring developers are giving Kotlin plenty of attention, making things interoperate smoothly. With that in mind, learning Kotlin for Android development could give you a bit of a leg up if you ever switched to backend development.

# ? Oct 8, 2019 18:02

Clockwerk: Apr 6, 2005

Kotlin is a crazy good language, considering that it's built to interoperate with Java and run on the JVM. Every time I use it I'm reminded how piss-poo poo terrible Java is and always will be

# ? Oct 11, 2019 22:16

ReverendCode: Nov 30, 2008

Kotlin is great, and if you are creating a dedicated Android app, it is recommended over Java. If, however, you are creating a cross platform app, flutter or xamarin may be a better choice since you can manage a single codebase across all your platforms.

# ? Oct 12, 2019 15:38

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

I'm definitely keen to learn more about Kotlin, good thread! The place I've just moved to (as a C# .NET developer) have two or three Kotlin based Android apps so it's rocketed into my focus just now.

# ? Oct 26, 2019 05:26

smiling giraffe: Nov 12, 2015

I recently started a Android dev job with a Java programming background. About 60% of of our app is Kotlin, and anything new is done in Kotlin so I had to learn it fast. Now if i'm ever forced to do something in Java its just a pain. If you do it right, Kotlin will let you code faster, and with fewer bugs.

One of the more crotchety devs on the team doesn't like the type inference as it can make the code less clear, but I couldn't care less.

# ? Oct 26, 2019 17:58

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

I've been doing Flutter at work for several months. Once you get over the hurdle of understanding its somewhat weird UI paradigms it's pretty good. The main thing that bothers me is that Dart's type-safety (assuming you type things) is just loving awful, often failing at runtime for things that should have failed at build-time and would work fine at runtime if it wasn't doing runtime type checking for some reason, e.g. runtime throwing an exception that List<Subclass> is not a subtype of List<Superclass>, which works fine if you just type-assert it. (Similarly, its lack of null-safe types is frustrating after Typescript.)

One thing I was very pleasantly surprised by this weekend was I set up a Flutter dev environment at home, and it was actually easy to set up and get started, which is a big improvement over trying to set up all that node_modules/webpack/babel malarkey for a Typescript project.

It does seem likely that Kotlin will be the winner, just because Flutter comes across as not very thoughtfully engineered. For example, there's no standard control for a 2D draggable viewer (with or without pinch-zoom support). Someone in the open source community is trying to add one (InteractiveViewer), which so far hasn't been responded to at all by the repository owners, and multiple requests for this kind of feature have been dismissed, even though it seems like a no-brainer as a feature that would be commonly desirable. It seems weird that single-axis scrollable widgets have been implemented separately, rather than having been implemented in the first place as a specialization of this more generic widget. There's also things where it's unclear if they're bugs or intended behavior, like a Stack widget with overflow:Overflow.clip, containing a Transform widget that positions its contents outside the bounds of the Stack, results in unclipped contents, visible outside where you'd expect them to be. When people file a bug about this kind of thing, the team asks the filer to include a minimal reproduction of the bug, even though it's trivially reproducible.

Edit: also a weird lack of interest in supporting an OpenGL widget, which seems like another thing that there'd be a lot of demand for.

roomforthetuna fucked around with this message at 07:11 on Nov 11, 2019

# ? Nov 11, 2019 07:09

is that good: Apr 14, 2012

Just rolling in for a sanity check. Is there any way to make the default parameter value work below?

code:


class Foo<T : Any>(val a : T) {
  fun <U> Bar(b : U = a) : U {
    // code goes here
  }
}

This fails to compile with "Type mismatch: inferred type is T but U was expected".

The alternative is always defining an overload:

code:


  fun Bar() = Bar(a)

But it would be nice not to need to do this every time it pops up.

is that good fucked around with this message at 07:04 on Dec 16, 2019

# ? Dec 16, 2019 06:54

Naar: Aug 19, 2003; The Time of the Eye is now; Fun Shoe

Allstone posted:

Just rolling in for a sanity check. Is there any way to make the default parameter value work below?
code:
class Foo<T : Any>(val a : T) {
  fun <U> Bar(b : U = a) : U {
    // code goes here
  }
}

I don't quite understand what you want to do here, are you trying to convince the compiler that U will always be a subtype of T? The easiest way I know of stopping it from complaining if you know that's always the case is something like this:

code:

class Foo<T: Any>(val a : T) {
    fun <U> bar(b: U = a as U) : U {
        // code goes here
    }
}

# ? Dec 18, 2019 12:32

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Doesn't U need to be a supertype of T here?

# ? Dec 18, 2019 22:07

is that good: Apr 14, 2012

Hey, sorry for taking a bit to respond. T and U have the same constraint. The intent is that when b is omitted, U should default to T. Adding the cast seems to have worked while preserving type information, which is most of what I was after.

For context on what I'm trying to do, I'm porting a Page Object Model library from C# to Kotlin. With slightly more context, the example looks like this.

code:

class Link<TParent : Page>(val parent : TParent) {
    fun <TDestination : Page> Click(route : () -> TDestination = { parent } as () -> TDestination) : TDestination {
        // Selenium stuff
        return route()
    }
}

# ? Dec 23, 2019 05:50

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

By "same type constraint", do you mean T should always be the same type as U?

If so, why does U even exist, why not just refer to T everywhere?

If not, what are some examples of cases where U and T might differ, and what should happen in those cases?

# ? Dec 23, 2019 07:08

is that good: Apr 14, 2012

T and U are both constrained to be some page (or page section) model type, not necessarily the same specific type.

They're separate because it's generally necessary to specify the page that interacting with a control causes to come into focus.

They're being linked here because in a lot of cases, interacting with a control doesn't change which page is loaded, so the control's parent page is used often enough to use as a default.

So for our example, some links and buttons just alter the current page, and so the method should just return the parent page model. Otherwise, a lot of links move to a different page, so it's necessary to return a model for the new page

The inspiring library just doesn't provide this default. I'm trying to exploit Kotlin's ability to use default parameters that aren't compile-time constant, but it might just be better to have separate methods.

Edit: here's an example with a pretty stubby page model, and model use.

code:

class LoginPage : Page {
    // These are controls defined like my last example
    // The actual constructors will also have a parameter for Selenium to find the corresponding element being modelled
    val UsernameField get() = TextField(this)
    val PasswordField get() = TextField(this)
    val LoginButton get() = Button(this)
}

code:

// Misc session setup
(LoginPage instance)
    .UsernameField.Fill("John") // Returns the LoginPage object
    .PasswordField.Fill("1234")
    .LoginButton.Press { UserHomePage() } // Returns an object modelling the destination HomePage

is that good fucked around with this message at 11:13 on Dec 24, 2019

# ? Dec 23, 2019 15:00

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

So how does the compiler know what type to infer for U if you're calling the parameterless version?

If you're wanting it to be inferred from the calling context, what happens if someone calls it in a context where a T doesn't fit?

I think providing the non-generic overload is probably better than trying to be overly-clever with default parameters.

# ? Dec 24, 2019 09:48

is that good: Apr 14, 2012

The idea would be that the compiler infers the type of the parent page when called without a parameter.

I'm not 100% sure what you mean by 'context where a T doesn't fit. If you mean a context where a Control doesn't have a parent, they're required to by inheritance, and are provided it statically by the page object class definition. Sorry, it looks like I clove much more to simplicity than context in the examples I gave.

(Also I've cleared up some confusion in the last example; the methods are called from a LoginPage instance, not from a singleton or companion.)

Yeah, I think I agree - the cast seems to work, but a major positive of the inspiring framework has been that it's easy to understand and to define new Controls for. My main question was if I was missing some obvious syntax for helping the compiler infer the type parameter from the default value.

is that good fucked around with this message at 11:16 on Dec 24, 2019

# ? Dec 24, 2019 11:12

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

I'm not sure exactly what you're doing (an interface or composition wouldn't be better?) but you might want to look into the reified keyword (gives you access to the type in a function and the is and as keywords work) or sealed classes (you can define various classes under a single type, and do pattern matching to identify what it actually is)

# ? Dec 26, 2019 14:48

is that good: Apr 14, 2012

The grail here is easy to define page models while maintaining compile-time type safety.

It's mostly a convenience question and I haven't explained it very well. I might just post the git with some examples once I have it at the point where I actually need to make the decision.

# ? Dec 27, 2019 02:19

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 23:38

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

well what I mean is, at some point something's gonna have to interact with those Pages, right? And either they have a common interface so the client doesn't need to know what specific type they are (and all the type-specific behaviour is encapsulated), or the client needs to do some type checking so it can interact differently with each model as required

the problem with your generics examples is you're specifying two types (Parent and Destination) which are both subtypes of Page, but that says nothing about their relationship to each other. Like any two classes are subtypes of Object (or Any since we're Kotlining), but you can't just use them interchangeably unless you're going to treat them both as that supertype, and only call the Object (or Any) methods, which are the only ones you can guarantee they both have

casting is sort of a hack where you say "ok you'll just have to trust me that Parent can always be treated as a Destination" because your code structure doesn't provide that guarantee for the compiler to check against. Either that's true (in which case, why not make Parent a subtype of the Destination type you're returning from your function - or just return a Page since that's what they both are) or it's not, in which case the calling code will have to do some type checking on the result before it can safely call any Destination methods

it really depends on what you're doing - if you want to get Pages from a Link and just Do A Thing with them no matter what that page actually is, maybe you need to design your system so it just returns Pages with a consistent interface, and all the distinct stuff for each type is handled internally. If you really need to know exactly what type of Page you just got back, you can do some checks with is, or use sealed classes which give you exhaustive pattern matching (you can define a Page class and then all your subtypes within it, they can be completely unrelated structurally, then you can use when on a Page instance to identify its specific type and take different actions depending on what you have)

# ? Dec 27, 2019 17:05

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Kotlin for Android