applicationOpen event not firing

Solar2D General Questions/Discussion
#21

Hey guys - just want to post here and answer Haakon publicly as well. I just wrote an email to him personally as well answering an email he sent me.

We do try to fix everything possible and we do fix *many* things. It is inevitable that all our developers think that whatever bug/issue they are facing is the most important thing at that point in time. For us that is rarely the case - but we still make an effort to fix as many things as possible. But we have to juggle the needs of thousands of developers, that’s just the way it is.

I will take a look at this and see if I can have one of the team take a look as well. I cannot guarantee how soon we will be able to address and how long it will take to fix the issue (assuming there is something to be fixed - I am coming at the issue cold and don’t know what it is).

David [import]uid: 10668 topic_id: 29587 reply_id: 124754[/import]

#22

Hi @haakon,

sorry to hear all your “drama” with the SDK as am following it here BUT I would like to ask you if I understood correct what you said above:

– Did you have to pay for Corona for them to “repair” a bug quickly and so it will be on the next daily build as you said?

If it is like this I sincerely did not know about this: if you pay you got and if not you keep yourself with the bug. (and our annual payment does not count?) o.O
Strange things going on…

[import]uid: 89165 topic_id: 29587 reply_id: 124759[/import]

#23

@RSCDev - I want to be clear about this. Haakon took the initiative and decided to “pay us so that we would solve the bug”. I was very clear in my post above that we will look at this and see if we can solve it based on all the other work we have right now on our plate. I will then settle with Haakon whether he has to pay for this or not. I have yet to understand if this is a bug, what the real problem is and what the fix will entail.

Again, I want to be very clear: we (Corona Labs) are NOT requesting that developers pay us to fix bugs. Like any other platform, we have a prioritized list of bugs and are working to address them. Each developer has specific bug that are important to them. We, fortunately, have to juggle the needs of thousands of developers and we therefore have to act accordingly and prioritize.

Thanks guys. [import]uid: 10668 topic_id: 29587 reply_id: 124762[/import]

#24

Mr. David Rangel ,

I “personally” thank you for being so clear about the @haakon`s issue right now. I understood what you meant.

BTW, this typed sentence of you below told me what I was looking forward to know:

Again, I want to be very clear: we (Corona Labs) are NOT requesting that developers pay us to fix bugs.

So, that was exactly what I always had in mind (since becoming a Coronas dev more than a year ago by now) and if it did not change by any way, well, it is good to hear about. PS: Ive posted above asking @hakoom before you and so I did not notice your post of course. The time of the post means nothing as am at different FUSO than you and so my machine`s time get into anyway. (am actually 5 hours or so in “front of you”) :slight_smile:
Best regards,
Rodrigo Costa. [import]uid: 89165 topic_id: 29587 reply_id: 124767[/import]

#25

I can attest to the fact that Ansca (sorry…Corona Labs) does in fact work on verified submitted bugs; however, the timeframe isn’t ideal unless you pay for premium support (which I can only guess at the quality of since I haven’t springed for it). It’s particularly frustrating if you’ve already paid $350 as a Pro Developer, but the sheer magnitude of the Corona SDK developer community I’m sure makes it near impossible to respond to every service request within the desired amount of time.

That being said, I would like to reiterate what I’ve read from other developers in other threads on this site: it would be nice if a little more emphasis was placed on the non-gaming features of Corona (i.e. the widget API). I’ve noticed in the recent Daily Build summaries that a lot of work is being done in this regard for Android, but the widget API is not what I would exactly call production level for iOS yet though. Just to mention a few of the bugs I’ve been wrestling with (which have already been identified in other threads): storyboard API transitions (i.e. slide), tableViews (in general, it’s feel as a “native” object is less than ideal, but more specifically as it relates to storyboard slide transition), and webviews’ lack of high level interactIon with Lua. I feel there’s a significant community of developers and potential developers who would be greatly benefitted by such attention from the Corona folks. [import]uid: 44153 topic_id: 29587 reply_id: 124795[/import]

#26

We’re not able to reproduce the warm start issue; it’s working as expected.

Based on this simple test case (https://gist.github.com/3759412), we see the following:

(a) On a warm start, we launch the app directly (tap on the icon from the home screen). We get the “applicationOpen” event as expected.
(b) On a warm start, we launch the app by typing “haakon://” into Safari. We get the “applicationOpen” event as expected.

Now specifically, for Facebook’s “fbXXXXX” urls, you will *not* see “applicationOpen” events b/c that’s how Facebook’s iOS library wants — they want the library to handle the urls under the hood, so that event does not get propagated.
[import]uid: 26 topic_id: 29587 reply_id: 124822[/import]

#27

So, Walter, how can deep linking from Facebook be achieved in Corona then? The whole idea of apprequests is that it deep links back to the app. It works fine on cold start, but no event.url is found on warm start. If what you write was true, the cold start should not have a facebook deep link url either… [import]uid: 21746 topic_id: 29587 reply_id: 124825[/import]

#28

Actually, in my test project, it’s the opposite. There is no event.url on cold start. In the test project above, if you do a cold launch via “haakon://” in Safari, you do not get an “applicationOpen” event — same would go for fb urls. [import]uid: 26 topic_id: 29587 reply_id: 124837[/import]

#29

Well, I can be a bit more precise with 2 use cases:

Corona App is not running (cold start)

  1. Click AppRequest in Facebook App.
  2. It opens up our Corona built app
  3. The fbXXXX url scheme is available in the launchArgs
    => Success

Corona App is suspended (warm start)

  1. Click AppRequest in Facebook App.
  2. It opens up our Corona built app
  3. There is no fbXXXX in the applicationOpen event.url - there is no applicationOpen event firing at all
    => Failure

I just asked the engineers over at Facebook if they have a limitation like you describe above, and they tell me there’s no such limitation. You are allowed to forward the deep link also on warm start. [import]uid: 21746 topic_id: 29587 reply_id: 124840[/import]

#30

Ah, okay. Why didn’t you say it like that earlier? :slight_smile:

It’s much clearer the way you explain it now — and incidentally, this is why we ask for code because that is always more precise and eliminates ambiguity.

Let me get back to you. [import]uid: 26 topic_id: 29587 reply_id: 124843[/import]

#31

@walter

While I didn’t provide sample code when I started this thread, the problem was described very clearly. Maybe you should read the entire thread before responding. [import]uid: 44153 topic_id: 29587 reply_id: 124875[/import]

#32

@j735, in retrospect, I agree, but hindsight is 20-20. The reality is the test code the team made and that was passed around wasn’t testing the right thing. @haakon’s precise description helps us refine it properly.

However, practically speaking, we still prefer to have the code. It saves everyone time, and more importantly, we can verify we fixed the actual issue. [import]uid: 26 topic_id: 29587 reply_id: 124927[/import]

#33

@walter

I hear you. You’re probably picking up on a bit of frustration I’ve been feeling over the fact that I started this thread over a month ago and the only response I received from a Corona staff member (Tom) before your post this week was not only dismissive in tone, but completely and utterly WRONG – I expect a staff member to at least check his employer’s documentation before chiming in on a developer discussion.

BTW, is there an ID number for this bug yet? [import]uid: 44153 topic_id: 29587 reply_id: 124944[/import]

#34

Yeah, once again I have pulled up my Credit Card to PAY Corona Labs for fixing their own bugs, so expect to see this fixed in a daily build in a couple of days.

I HATE the way Corona Labs treat their customers (us), but unfortunately we’re stuck with your SDK for a while and just have to take what we get. We’re not your best ambassador, though. [import]uid: 21746 topic_id: 29587 reply_id: 124750[/import]

#35

Hey guys - just want to post here and answer Haakon publicly as well. I just wrote an email to him personally as well answering an email he sent me.

We do try to fix everything possible and we do fix *many* things. It is inevitable that all our developers think that whatever bug/issue they are facing is the most important thing at that point in time. For us that is rarely the case - but we still make an effort to fix as many things as possible. But we have to juggle the needs of thousands of developers, that’s just the way it is.

I will take a look at this and see if I can have one of the team take a look as well. I cannot guarantee how soon we will be able to address and how long it will take to fix the issue (assuming there is something to be fixed - I am coming at the issue cold and don’t know what it is).

David [import]uid: 10668 topic_id: 29587 reply_id: 124754[/import]

#36

Hi @haakon,

sorry to hear all your “drama” with the SDK as am following it here BUT I would like to ask you if I understood correct what you said above:

– Did you have to pay for Corona for them to “repair” a bug quickly and so it will be on the next daily build as you said?

If it is like this I sincerely did not know about this: if you pay you got and if not you keep yourself with the bug. (and our annual payment does not count?) o.O
Strange things going on…

[import]uid: 89165 topic_id: 29587 reply_id: 124759[/import]

#37

@RSCDev - I want to be clear about this. Haakon took the initiative and decided to “pay us so that we would solve the bug”. I was very clear in my post above that we will look at this and see if we can solve it based on all the other work we have right now on our plate. I will then settle with Haakon whether he has to pay for this or not. I have yet to understand if this is a bug, what the real problem is and what the fix will entail.

Again, I want to be very clear: we (Corona Labs) are NOT requesting that developers pay us to fix bugs. Like any other platform, we have a prioritized list of bugs and are working to address them. Each developer has specific bug that are important to them. We, fortunately, have to juggle the needs of thousands of developers and we therefore have to act accordingly and prioritize.

Thanks guys. [import]uid: 10668 topic_id: 29587 reply_id: 124762[/import]

#38

Mr. David Rangel ,

I “personally” thank you for being so clear about the @haakon`s issue right now. I understood what you meant.

BTW, this typed sentence of you below told me what I was looking forward to know:

Again, I want to be very clear: we (Corona Labs) are NOT requesting that developers pay us to fix bugs.

So, that was exactly what I always had in mind (since becoming a Coronas dev more than a year ago by now) and if it did not change by any way, well, it is good to hear about. PS: Ive posted above asking @hakoom before you and so I did not notice your post of course. The time of the post means nothing as am at different FUSO than you and so my machine`s time get into anyway. (am actually 5 hours or so in “front of you”) :slight_smile:
Best regards,
Rodrigo Costa. [import]uid: 89165 topic_id: 29587 reply_id: 124767[/import]

#39

I can attest to the fact that Ansca (sorry…Corona Labs) does in fact work on verified submitted bugs; however, the timeframe isn’t ideal unless you pay for premium support (which I can only guess at the quality of since I haven’t springed for it). It’s particularly frustrating if you’ve already paid $350 as a Pro Developer, but the sheer magnitude of the Corona SDK developer community I’m sure makes it near impossible to respond to every service request within the desired amount of time.

That being said, I would like to reiterate what I’ve read from other developers in other threads on this site: it would be nice if a little more emphasis was placed on the non-gaming features of Corona (i.e. the widget API). I’ve noticed in the recent Daily Build summaries that a lot of work is being done in this regard for Android, but the widget API is not what I would exactly call production level for iOS yet though. Just to mention a few of the bugs I’ve been wrestling with (which have already been identified in other threads): storyboard API transitions (i.e. slide), tableViews (in general, it’s feel as a “native” object is less than ideal, but more specifically as it relates to storyboard slide transition), and webviews’ lack of high level interactIon with Lua. I feel there’s a significant community of developers and potential developers who would be greatly benefitted by such attention from the Corona folks. [import]uid: 44153 topic_id: 29587 reply_id: 124795[/import]

#40

We’re not able to reproduce the warm start issue; it’s working as expected.

Based on this simple test case (https://gist.github.com/3759412), we see the following:

(a) On a warm start, we launch the app directly (tap on the icon from the home screen). We get the “applicationOpen” event as expected.
(b) On a warm start, we launch the app by typing “haakon://” into Safari. We get the “applicationOpen” event as expected.

Now specifically, for Facebook’s “fbXXXXX” urls, you will *not* see “applicationOpen” events b/c that’s how Facebook’s iOS library wants — they want the library to handle the urls under the hood, so that event does not get propagated.
[import]uid: 26 topic_id: 29587 reply_id: 124822[/import]