2cloud 2.1 Beta Available Now

[Paddy Foran]

Testers, start your engines. We have a new beta available for you.

This one's pretty important; it features a completely refactored codebase for all three pars (Chrome, Android, and the server). We'd love to get them tested pretty thoroughly before rolling it out to the public. So put this through its paces.

More importantly, this version also implements our quota and adds in-app payments to get around it. For more information on this, see our blog post: http://blog.android2cloud.org/2011/07/they-grow-up-so-fast.html. We're going to be setting the quota levels to different things during the test to make sure it's functioning how we expect it to. This will give you plenty of opportunities to buy your way around it. There is one caveat to that, though: every time you buy your way around it, your credit card will get charged $1. I'm really sorry, I wish there were some way around this. But Google doesn't provide a beta testing capability for in-app payments. We're not looking to make money off your testing, though; we'll be refunding charges to you as we receive them. I will make sure each charge initiated during this beta period gets refunded.

We've also switched up the way account authorization works. We now launch your default browser to handle the access approval. This means if you're logged in to your Google account in your browser, you don't need to log in again.

Finally, the icon has made its return to the Chrome extension area. Also, it has some useful metadata and functions associated with it, now. A blank icon means the extension is trying to connect to the server. A green dot on the icon means the extension has successfully connected to the server-- clicking it will disconnect you. A white dot means the extension is disconnected-- clicking it will connect you. A red dot means the extension got an error from the server. Click the icon to see more information about the error. If you forget what a dot means, just hover over the icon, and you'll be told.

We've tried to fix a lot of bugs with this. If you run into any bugs, any at all, please do report them. We're trying to squish them pretty rapidly.

We'll be running this beta until July 18th. I know, I know, that's hardly any time. I don't like it either. Unfortunately, events outside my control are dictating the schedule a bit. If you report a bug after that it may be fixed by launch, but I can't promise that. It may have to be patched in a new release.

You can download the Android APK here: http://goo.gl/v03mq. You should be able to just download and install it on top of the Market version.

You can download the Chrome CRX here: http://goo.gl/MJJwD. You'll have to uninstall the Web Store version and install this new version. Please remember to uninstall the new version and switch back to the Market version on the 19th when we announce the public release.

The new server can be found at https://2cloudapp.appspot.com. This should be auto-populated into the app and extension when you download them.

Thanks for all your hard work and support. We appreciate it.

Thanks,

Paddy Foran

[Ahmed Al-Sudani]

Paddy,

I'm having a problem with the android app not catching the OAuth callback. The authentication would go fine, but when it's done, I'm redirected to a "2cloud.app" http url, and the app does not take over from there.

They do indeed grow up: the new extension design, the browser button, the external authentication, not to mention the other more important changes :) Mind-blowing if you consider the length of time you had.

Thank you, and fix it soon I need to do my testing ;)

-Ahmed

[Joseph Adams]

Hi Paddy,

I am also having the same problem as Ahmed. The App doesn't take over after authentication with Google.

I've not come to the chrome part yet but I've heard it's fantastic ;)

Hope you can solve the problem.

Joseph

--
Joseph Adams

E-mail: white...@googlemail.com
Website: http://www.pipetree.com/josephadams

[Steltek]

I seem to have the same problem with the OAuth callback not going back. Instead of returning to the app, the web browser tries to open http://2cloud.app/oauth/callback/?host=/.......  and that fails.

[Steltek]

Replying to myself, this line here seems to be the culprit:

https://github.com/2cloud/android2cloud/blob/rewrite/src/com/suchagit/android2cloud/util/OAuth.java

23:

	private static final String CALLBACK_URL = "http://2cloud.app" + CALLBACK_PATH;

At least that is where that '2cloud.app' bit appears.

[Paddy Foran]

Hey everyone,

Sorry for the issue. And the brief reply-- I'm in the process of catching a train as I write this.

The redirect to 2cloud.app is supposed to happen, but the app is supposed to intercept it. You should get a dialog asking whether to open with the browser or the app. If you aren't, could you chime in with the browser, phone, and android version you're using?

Thanks,
Paddy

[Ahmed Al-Sudani]

You're right, the app does take over from there.

I had to use the default Android browser. One thing I noticed is it asked me what browser to use at every redirect, so it probably broadcasts the links to Android as intents. I mainly use Dolphin as my browser, and apparently it handles all links internally. I'm pretty sure though that it would throw out something it can't handle, say "2cloud://..."

Something other that http would also be more convenient, as 2cloud would automatically take over.

[Tomáš Kaluža]

Hello Paddy, 

I am having the same problem. I am using HTC Desire with Android 2.2 and the default Android browser. I do not remember to tell the browser to take all these links, but it tries to open the link in the browser and does not succeed. 

How could I authenticate in this case?

Tomas

[Steltek]

I tried having the app open the link, but that only opened the app with its main screen. (URL, Device and Send button) When trying to go back, I get stuck in a loop with that screen popping up over and over again, unless I hit back quickly in succession and get back to the browser that way.

Samsung Galaxy S - Android 2.3.4

[Joseph Adams]

Hi again

As requested I am using a Galaxy Tab 10.1 from I/O with Android 3.1 and the default Android browser.
I am quite new to Android programing and am trying to learn from this, so probably a stupid question: Where is the actual intent-filter? I am used to finding it in the Android manifest but I am probably just not looking for it hard enough in the accual code.  

Joseph

--
Joseph Adams

E-mail: white...@gmail.com
Website: http://www.pipetree.com/josephadams

[Bruce Olson]

If I understand correctly, the intent filter is only placed in the manifest and is used by the system to find applications or Actions that can handle an intent. That is why you also specify the the Activity for the intent filter. Intent filters can also be used to start a Service or  Broadcast Receiver.

Here is more information about intent filters:

http://developer.android.com/guide/topics/manifest/intent-filter-element.html

[Paddy Foran]

Hi guys,

Thanks for putting this through its paces. :) This is why we beta test.

Sorry for the radio silence-- I've been out of town since Saturday morning, so I've been using my phone to monitor this thread. Which makes keeping up pretty easy, but replying a bit difficult.

I am aware of the protocol option available. However, I tried that originally and received an "Invalid URL" error from Google. My assumption was that Google would only allow http:// or https:// redirects after OAuth, but I could've botched something else. I'm going to monkey with it a bit tonight, and hopefully will have a new Android build for everyone in the morning.

Also, Michel mentioned that when the app opened the link, that just led to the main screen. If I'm understanding what he's saying, that is in fact the intended behaviour. The next build will hopefully make this a bit clearer.

Finally, it would be insane to roll out this upgrade in the next 24 hours, given the amount of confusion around the auth flow. Damn the consequences, we'll be releasing something that works as you expect it to. Therefore, the beta period is extended indefinitely (though I'd really like a rollout this week or early next week, if at all possible).

Thanks for your hard work. I'll be in touch shortly with a new build.

Thanks,

Paddy

[Paddy Foran]

Argh. It's as I feared. Unfortunately, Google's OAuth implementation appears to reject any callback to a protocol besides http or https. Which makes this difficult.

I've emailed the App Engine mailing list (https://groups.google.com/d/topic/google-appengine/eDG_RO1dXFM/discussion) and am working on some alternate solutions. Hopefully they'll get back to me and have a fix. I doubt it will be any time soon, though. In the meantime, I'm going to work on a hosted callback. Essentially, it'll accept the callback response and simply redirect to the app's callback. This will let us provide an HTTP/S callback URL, but still give us the functionality we're looking for.

Unfortunately, it's three a.m. and I need to sleep. Tomorrow I'll set up the redirect and send out an updated Android client. Thanks for your patience.

Thanks,

Paddy

[Steltek]

Hello,

Difficult to explain but yeah, what I get after accepting the authentication is a popup where it asks me which application to open it with (default browser which I used up to there, Firefox, Opera or 2cloud...) and selecting 2cloud, the app pops up on the main screen (destination device pre-filled as 'Chrome', URL empty) as if I had launched it normally.

Unfortunately from there, I can't do anything. Trying to share a URL does not work (type it in, hit Send, nothing happens) so somehow the app doesn't seem to properly pick up the authentication. It also isn't possible to get back out of the app easily. Hitting back, the main screen goes away only to be replaced by another instance of itself.... I have to spam the back button rapidly which eventually makes the phone jump back into the still open browser session where the authentication was taking place and then back into the 2cloud app instance where the authentication was initiated from and finally back to my home screen.

Once through that, the app seems to think it is set up (it does not prompt for initial setup any more) but sending links still does nothing.

[Paddy Foran]

Alright, I've done a bit of work and research on this in the last two days, and I think I have a firm grasp on the options:

1. I can leave the flow the way it is, but try to support the majority of (if not all) the browsers. This would just be a matter (I think) of setting the Intent Filter to the most broad definition I possibly can while still getting only correct matches. Seeing as 2cloud.app doesn't and can't exist, I'm pretty sure just filtering for anything that has a data attribute with a host of 2cloud.app will work. That should match any browser that uses the Intent resolvers to process links-- if they don't, there's pretty much nothing I can do.
2. I can implement the accounts API. Pros are that you don't have to login, you just choose the account you already have on your phone. Cons are we screw the 200+ users who are still stuck on 1.5 and 1.6, and thus don't support the accounts API.
3. I can revert to the WebView method, in which the app handles everything in a browser window inside the application. Pros are that it's tried and tested and will work. Cons are security issues (you just have to take my word/the source code's word that I'm not logging your credentials) and the lack of login state storage-- you'll have to log in to authenticate, even if you're already logged in in your default browser.

I'm torn between whether to opt for 1 or 3. I'd like to do an Android version for the latest and greatest, using features like C2DM, ContentProviders, the Accounts API, and tablet support in the near future (e.g., next month or two), but I need to figure out what to do with the current version in the meantime. Which, as users, would you prefer? Is there something I'm not considering?

[Lorenzo "Lohoris" Petrone]

On 20 July 2011 09:01, Paddy Foran <pa...@2cloudproject.com> wrote:

• I can implement the accounts API. Pros are that you don't have to login, you just choose the account you already have on your phone. Cons are we screw the 200+ users who are still stuck on 1.5 and 1.6, and thus don't support the accounts API.

This is the way to go.

It's sad some people won't be able to use it any more, but not implementing the native login causes a lot of bore to all the others, and makes the application look very unprofessional.

Think of the future. Less and less people will be stuck with so-old systems, and your app will already be working the right way.

--
venera Lo'oris su http://looris.net

[Michel]

On 20/07/2011 10:47, Lorenzo "Lohoris" Petrone wrote:
> On 20 July 2011 09:01, Paddy Foran <pa...@2cloudproject.com

> <mailto:pa...@2cloudproject.com>> wrote:
>
> # I can implement the accounts API. Pros are that you don't have to

> login, you just choose the account you already have on your phone.
> Cons are we screw the 200+ users who are still stuck on 1.5 and 1.6,
> and thus don't support the accounts API.
>
>

> This is *the* way to go.

>
> It's sad some people won't be able to use it any more, but not

> implementing the native login causes /a lot/ of bore to all the others,

> and makes the application look very unprofessional.

I agree, my personal preference would be Nr 2, just because it is secure
and 'not hackish'. I am wondering: Would it be possible to have Nr 2 and
Nr 3 as fallback for the older devices? (Can Android Apps recognize the
API they're running on and react accordingly? Do they even run when an
app has elements of a newer API? Or does this boil down to having to
maintain two versions of the app?)

- Michel

[James]

I also concur that number 2 would be the best way forward. It makes
an app seem more modern and professional, and it will work for 90%+ of
users. Most people who are in to technology (and would therefore be
the ones likely to use 2cloud) won't be on 1.5 or 1.6 now, or if they
are, it won't be for too long - just til they upgrade.

Check this chart and see how few people it will impact:
http://developer.android.com/resources/dashboard/platform-versions.html

[Paddy Foran]

I actually have a relatively up-to-date statistics dashboard in Android Market that shows what operating systems our app is installed on. We'll be leaving 234 people high and dry. I just announced we're deprecating support for anything below 2.1, anyways. http://goo.gl/1QzOw

I'm going to revert the authentication in the beta back to the WebView, which is tried, tested, and true. I'll implement some fixes (make it keep state on orientation, that kind of thing) and get an update out tonight (I hope). After some beta testing, I'd like to put a *done* stamp on this version and never touch it again. I'd like to begin building for 2.1+.

I can't promise features just yet, but here's what I'm gunning for:

• Device dropdown list, via a SyncAdapter (so it will be kept up-to-date)
• Cloud to device messaging support, so you can open links on your phone
• A tablet-optimised version of the app
• Account API support, so no more buggy OAuth dances!

That is my wish list. I'm sure that will grow and shrink as time goes on and I get new ideas and have to cut back on some to keep a realistic development schedule. I'd also like to get unit tests in place on that version, to cut back on the bugs fobbed off on you guys.

Thanks for all the hard work testing. I'll send out a new email thread (probably tomorrow) with a new beta to test, using the old WebView method.

Thanks,

Paddy

[Michel]

On 21/07/2011 04:39, Paddy Foran wrote:
> I'm going to revert the authentication in the beta back to the WebView,
> which is tried, tested, and true. I'll implement some fixes (make it
> keep state on orientation, that kind of thing) and get an update out
> tonight (I hope). After some beta testing, I'd like to put a *done*
> stamp on this version and never touch it again. I'd like to begin
> building for 2.1+.

Sounds like a great plan.

> I can't promise features just yet, but here's what I'm gunning for:
>

> * Device dropdown list, via a SyncAdapter (so it will be kept up-to-date)
> * Cloud to device messaging support, so you can open links on your phone
> * A tablet-optimised version of the app
> * Account API support, so no more buggy OAuth dances!

To be honest, I personally don't really see much use for c2dm since we
already have chrome2phone and QR codes. I never understood why Google
made chrome2phone go in the direction that it goes because I rarely want
to send a link to my phone. In fact, the only time I do, it's to
download a file and I've even started circumventing that by downloading
the file to Dropbox on the PC and having the device pull it down from there.

With that said, c2dm would make the system more feature-complete,
covering both directions and possibly also more browsers than Chrome in
the future.

Anyway, can't wait for the new beta. I've been too lazy to revert to the
production version and am starting to suffer from '2cloud withdrawal'. ;)

- Michel