
Google to change its policy on mobile apps. Native apps to come. - barredo
http://thenextweb.com/mobile/2011/01/31/google-to-change-its-policy-on-mobile-apps-native-apps-to-come/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheNextWeb+%28The+Next+Web+All+Stories%29&utm_content=Google+Reader
======
Pewpewarrows
Interesting to hear this right around the same time that Facebook announces
devoting more resources to HTML5 because of the challenges involved in
deploying updates to several different native mobile apps.

~~~
wallflower
If Facebook really wanted to "relieve" itself of the burden of maintaining
native apps on everything from Blackberry to WinMo, they would open source the
apps. Of course, this would require giving the public dev community access to
internal Facebook/hidden APIs. There could be some really interesting apps if
they weren't sandboxed into the restrictions of Facebook's public APIs. Giving
more access cedes control and gives arms to spammers and hackers.

Since a vocal minority will cry foul and presumably rally support (create a
Facebook fan page) if an existing native app like WinMo was dropped, it is a
smart long-term strategy to converge to HTML5.

Google's strategy is to get more people using their apps, period. There must
be an order of magnitude (or more) difference in how many people play Angry
Birds instead of Google Mobile version 0.7.3.5675

~~~
joe_the_user
Uh, can you give any references to "hidden" Facebook APIs?

Being in the process of currently developing a Facebook app, it seems to me
the entire graph is exposed. The only question is permissions and Facebook's
willingness to change APIs on a very regular basis (that is a dicey question
but rather different).

But "hidden" APIs??

You can find an open source Facebook library here:
<http://gitorious.org/qfacebook> as well as many other places for different
languages.

~~~
wanderr
There are most certainly hidden APIs, there are things that YouTube and Yelp
are allowed to do, that you just can't do through any of the publicly
documented APIs.

~~~
ramprabhu
The Yelp case isnt a hidden Api. Its (seems) more of a preferred Api Key. You
can do a view source on Yelp and get the facebook api URL Yelp runs to get
your name and birthday. but its essentially restricted to the above two fields
as I tried getting my other details through that URL by replacing the
user_name field with say user_location and Api failed saying the apik key
doesnt have permissions for that field.

BTW if all you want is to get some users name and birthday, you now have the
Yelp apikey ( You did not hear that from me ;)

~~~
wanderr
There are other calls they make completely behind the scenes that, as far as I
can tell, _are_ completely secret. I don't use Yelp very often so I may be
getting the terminology mixed up, but if you link your Yelp and FB accounts,
and you "star" or "like" (or whatever they call it) something on yelp, it will
automatically like it for you on Facebook _without_ sending any traffic
between your computer and Facebook. They're obviously hitting Facebook from
the server side, which would imply to me they're trying to keep the API call
secret.

~~~
ramprabhu
The way you do it would be to get the FB access_token in JavaScript, which is
given to you once you authorize yelp. With this you can make an Api call to
the api.facebook.com from any other computer. Its all public. Incase you
provide offline_access, this access_token is _almost_ valid for life (almost
as FB doesnt give a expiry time on paper)

~~~
wanderr
I understand how the API works, but there is no publicly documented call for
liking something for a user, whichh is what yelp and youtube are able to do.

~~~
wanderr
Looks like my phone went a bit nuts trying to post this reply, didn't notice
in time to delete them. Sorry for the spam!

------
magicalist
anyone else read the linked wsj article
[http://online.wsj.com/article/SB1000142405274870355420457611...](http://online.wsj.com/article/SB10001424052748703554204576112723686094898.html)
and think this is just google hiring more native app developers? considering
that google already has a bunch of native apps (wsj says 20), the whole "vs
html5" thing seems a bit much.

the only interesting part seems to be the "autonomous but with google's
resources" development model.

~~~
cpeterso
Google's Android NDK (Native Development Kit) had been mostly bare-bones libc
(and utility libs) for writing optimized C code to be called from Java/JNI.
But NDK Revision 5 (December 2010) includes new native APIs for application
framework and system APIs that were previously only available to C code
through JNI, such as window surfaces, event loops, and sensor data.

<http://developer.android.com/sdk/ndk/index.html>

------
lutorm
The apps I use most on my N1 is gmail, maps, voice and talk. All native apps.
I don't know what they are talking about Google "staying clear of native apps
on mobile devices"?

------
rchowe
Google already has some great native apps (the google app and google voice for
iPhone). They seem to only use native apps in cases where some functionality
isn't available in the browser, e.g. push notifications or accelerometer
control and speech to text.

~~~
zeedotme
agreed, but it seems that's going to change and native apps (even when the
functionality is available in the browser) are on the way.

~~~
rchowe
Well, what this means is that they expect the bump they get from being listed
in the app store over using web apps to be pretty significant (which I believe
it will be too).

------
omaranto
For apps that don't need special access to hardware and that can therefore be
written as web apps, whether a web app or native one would be better depends
solely on execution. On my iPod Touch there are 4 big examples of things I
prefer as web apps just because the available native ones aren't as good:
Gmail, Google Reader, Facebook and Hacker News. (Well, Gmail doesn't count
maybe: I mostly use the built-in mail app, but find the web app much much
better for searching and about equally good for normal use.)

I guess Google itself might make a better Google Reader native client than the
web app, but currently all of the 3rd party native clients have some annoying
minor problem: some don't have zoom for images, some don't have a "Like"
function, some don't display TeX formulas in wordpress math blogs properly,
one bizarrely turns the entire text of arXiv feeds into a link; none of the
native apps works perfectly on my feeds.

As for Facebook, the native app is not bad but it's noticeably slower than the
web app and only let's you like status updates not comments on them. I mainly
use the web app but do have the native app to upload photos on occasion (on my
previous, camera-less iPod I only used the web app).

Hacker News native apps probably suffer from a lack of API, so maybe it's not
fair to mention them, but if one worked properly I'd probably use it. I used
to use Michael Grinich's app (I hope I'm remembering his name correctly), but
recently it won't let me comment. That together with it being much slower than
either actual HN or iHackerNews, made me go web.

------
dotBen
As much as I'm a proponent of HTML5, the bottom line is that much of the
functionality Google might want to provide is not going to be available at the
browser/javascript layer.

Another reason Google has shunned Apple native apps in particular is because
of Apple's clear reluctance to accept them given Google's dominant position
(case-in-point: Google Voice). If Eric Schmidt is being lined up to become
Apple's next CEO then it would be a smart move for Google to pre-empt a more
favorable Apple era towards Google

~~~
loewenskind
>If Eric Schmidt is being lined up to become Apple's next CEO

Why on earth do people keep expecting this? Apple's success comes from their
fantastic design sense and their leading support. Schmidt gets a bad grade in
both those areas. Apple has other people already in the company that could do
a better job than Schmidt.

~~~
dotBen
I agree, which is why it would make more sense to leave the visionary stuff to
folks like Jony Ive and have Eric Schmidt run the company. (Ive is hardly a
CEO type)

Schmidt's job at Google was to provide "adult supervision" to Larry and
Sergey, and keep on top of the executive functions of a publicly listed
company.

There is no reason to assume he wouldn't do a good job at that with Apple,
leaving folks like Jony to be visionaries.

------
jackowayed
Finally.

Sticking with HTML5 for most stuff was a good idea in theory. It uses less
resources (and they already have tons of people that can do JS and HTML),
promotes HTML5, means they don't have to deal with Apple's BS, etc.

But the apps were awful (at least as of May, when I switched from iPhone to
Android). They felt unnative, had annoying UX at times, and generally sucked.
Plus there's a lot of APIs that webapps don't have access to.

The one issue for Google is that those shitty apps might have convinced some
people to switch to Android, where the Google apps are perfect. It definitely
was a factor in my switch.

------
tezza
I've had an integrated google search app for my Nokia E71 for more than 1
year.

<http://www.google.com/mobile/nokia-s60/>

------
awakeasleep
Anyone have any thoughts on the "Many small apps including games" bit of this
article?

Sounds like Mr. Page may have started taking steps to encourage more
entrepreneurial spirit in Google. Can you imagine how fun some of those
projects will be?

------
ericmsimons
This is a good step forward. It was a mystery to me why they weren't deploying
native apps across all platforms; mobile web just doesn't give you the same
feel and functionality.

------
yarone
optimize for the user

------
wslh
At least...

