Classes don't expose static fields from interfaces

[snekbaev]

Hi,

I'm using the aforementioned experimental build option and it is quite handy.

What I noticed though is that if there is an inheritance then it is not possible to access the base class field from the derived class. Say, Android has the Telephony.Sms.Inbox.BODY where Inbox is

public static final class Inbox implements BaseColumns, TextBasedSmsColumns

and BODY is defined in the TextBasedSmsColumns. What ends up generated is:

export class Inbox extends java.lang.Object implements android.provider.BaseColumns, android.provider.Telephony.TextBasedSmsColumns {
					public static CONTENT_URI: android.net.Uri;
					public static DEFAULT_SORT_ORDER: string;
				} 

and basically an attempt to use in a native-like way android.provider.Telephony.Sms.Inbox.BODY fails, instead I need to do android.provider.Telephony.TextBasedSmsColumns.BODY.

Something you may want to check out and some point :)

Thank you!

P.S.: also keeping the original parameter names instead of paramX would have been nice, though I guess that's in the works too :)

[petekanev]

@snekbaev just want to throw some light on the matter - the issue is a bit tough to tackle, as inheritance chain can easily become very complicated in Java, and thus Interfaces extend Interfaces, and classes then implement those interfaces, but down the line other classes overwrite the static fields of said interfaces, etc.
Classes in Java can have a property and a method with the same name, TypeScript classes can't. So there isn't a generic 1-shot solution.
I'll let you know if and when we've got update on this.

As for the 'P.S', keeping the parameter names is not possible with the current implementation (and the external API that we use), so it is not in the works currently.

[snekbaev]

@Pip3r4o yeah, that's what I thought.

Had to use Android Studio to figure out what is where. But I guess that anyone who needs some native functionality will have to implement it in Android Studio/XCode first and then port, otherwise it is quite time consuming and a painful journey.

Feel free to close the issue if needed. Thank you!

[petekanev]

@snekbaev I hope that you do know that the android documentation is a click away at https://developer.android.com/reference/packages.html . There are even certain chrome extensions that make browsing it even easier. The generator is in experimental stage, and inconsistencies are to be expected. It is not currently being actively worked on.

I personally consider developing with native functionalities to be easier now more than ever in JavaScript, with no need to open Android Studio, but there is still some way to go until it becomes streamlined. At the end of the day, it's about personal preferences.

[snekbaev]

@Pip3r4o I think you missed my point, I'm not saying it is about the generator per se, but the whole process of working with native stuff in a scope of VSCode, TS and NS. For the sake of this comment, let's scope it to productivity.

Let me elaborate: I'm a .NET Developer with AngularJS 1 experience. At the moment evaluating available technologies for mobile development. As for test project I decided to create an app that has two screens which can read, send, receive sms and update the UI accordingly. Started out with the then-current 2.3 NS in VSCode + NS plugin. Decided to go with Angular 2 + TS template. Both were new to me. Crafted the UI for the first screen, that experience was great. Next step - send the sms. First attempt was to find an existing plugin for that, the one discovered was actually opening the sms app whereas I wanted to send the sms directly, thus had to implement the solution myself. That led me to my first NS plugin creation attempt which was recreated the very next day using NS plugin seed project as the base. All that is fine so far. Now I had the structure and needed to implement the Android specific logic and this is when I ran into the joys of working with any variables like android. Because I was using TS I wanted to leverage the strongly typed objects which also help with intellisense. But I didn't have typings. Implementation became slow and frustrating: I was jumping around numerous NS plugins, samples and platform declaration files, saw people having exactly similar experiences. Eventually I got tired and did myself a favor: fired up Android Studio and recreated the current state of the application in there. You wonder whether I know where the documentation is, the answer is yes. Am I going to use notepad to work with it taking into account that there are much better free "intellisensed" alternatives, then answer is no.

Long story short, I implemented, debugged and tested the rest of the native functionality in Android Studio, learned about certain internals simply by navigating to corresponding methods (which are heavily commented) directly from the IDE. Then after some trial and error ported that code to my NS app. Keep in mind - all that was a first time experience for me. Also ran into situation when android17.ts wasn't helpful, because the required API was in 19. Then 2.4 came along, I used the generator and got rid of the most anys.

That NS app is almost complete, I put it aside after running into several other issues (most reported). Now have successfully recreated and completed the very same app using Xamarin Android. Next will need to check out the RN.

All in all, right at this moment as the person who is new to all these I will say it is much easier and much more productive to write/debug/test native code snippets using own IDEs and then port to NS. The mentioned future/potential streamlining does have some serious competition, thus expectations.

Will see in a year or two :)

P.S.: as a side note, the further I proceed with the evaluation of available mobile development frameworks the more it feels like platform differences should actually be embraced rather than brought to the common denominator :)