582621 - Sharing back-end for MeeGo

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

Allow the new Sharing feature in Fennec 2.0 to discover, list, and launch
third-party Maemo/MeeGo applications.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

We need to look into the Maemo/Meego application registry, or maybe the *.desktop files. We need to come up with a way to discover that an application can handle certain types of data.

Or maybe we need a way for an application to say "You can pass me data, like text snippets and URLs, using this DBus method"

Comment 2

[Arto Hamalainen]

Attachment: MeeGo Touch libshare-ui usage example

For your information, MeeGo Touch ShareUI provides ShareUiInterface() class with Share() method to share data of following form with supported methods (email, sms, ?).

"data:text/x-url;title=This%20is%20title;description=And%20this%20is%description,http%3A%2F%2Fstore.ovi.com"

In addition to actual content (url, text snippets, ...), it supports "title" and "description" fields that are included in shared data. 

Attached is relevant parts of our test extension that uses this share-ui interface to share bookmark URLs. This results MeeGo Touch Share UI being shown which user can use to select the method of sharing.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Arto - is the share-ui interface documented anywhere? I am wondering if we can do more than just blindly hand off to the app. I want to be able to enumerate the possible handlers too.

Comment 4

[Arto Hamalainen]

I don't know if there's public documentation available or what's the status of the API. I'll ask around and study the code to see what is and will be there.

Comment 5

[Andrey Petrov]

Mark, we spoke to MeeGo people in charge of the API and their take is simple. Apps are expected to blindly set mime type for data and let the framework do the dirty work. They are quite solid in their opinion, because it was revisited several times already. 
Currently for media they support already Youtube, Picasa, Flickr and Bluetooth/MMS
For url they support already Facebook, Twitter, Email, and SMS.

So that doesn't sound really bad to me at all.

Comment 6

[Andrey Petrov]

Also, Sharing framework is now in the process of going open.
Additionally, by using Share FW users immediately take advantage of SSO built-in.

Comment 7

[Matt Brubeck (:mbrubeck)]

Unassigning - somebody with a MeeGo dev environment should work on integrating this into Fennec.  It will eventually use the interface sketched out here:  http://etherpad.mozilla.com:9000/sharing-interface

I can try to work on this if necessary, but I'll need to see if I can run MeeGo under scratchbox/x86 with Xephyr.

Comment 8

[Matt Brubeck (:mbrubeck)]

Note: If getSharingApps returns just one result on MeeGo, then we will invoke that app immediately rather than displaying an in-browser UI to select an app.

Comment 9

[Tero Turtiainen]

I have access to MeeGo dev environment, so I can take this.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

moving to beta 2, but we definitely need some Meego help to move this forward.

Comment 11

[Doug Turner (:dougt)]

tero any update?

Comment 12

[Tero Turtiainen]

(In reply to comment #11)
> tero any update?

I have a working MeeGo back end which is based on bug 582616. However, my work depends on a yet unfixed bug on MeeGo libraries, so it is not really generally usable yet. Basically a MeeGo sharing interface is currently missing pkg-config support.

Comment 13

[Oleg Romashin (:romaxa)]

> usable yet. Basically a MeeGo sharing interface is currently missing pkg-config
> support.

Tero do we have blocker bug against Meego sharing interface component?

Comment 14

[Tero Turtiainen]

Attachment: Patch

Patch which uses the interfaces and services introduced in bug 582616. Works with Fennec version which has the patch from bug 598269.

Meego sharing interface has been updated in their repository (the missing pkg-config...). I don't know yet when it will be released.

Comment 15

[Doug Turner (:dougt)]

Comment on attachment 480585 [details] [diff] [review]
Patch

stealing review.

Comment 16

[Doug Turner (:dougt)]

Comment on attachment 480585 [details] [diff] [review]
Patch

how is MEEGOTOUCH different than MEEGOTOUCHSHARE?  Can you ever have a MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

@@ -115,6 +115,8 @@ NS_GENERIC_FACTORY_CONSTRUCTOR(nsDBusHan
 #endif 
 #ifdef ANDROID
 NS_GENERIC_FACTORY_CONSTRUCTOR(nsExternalSharingAppService)
+#elif defined(MOZ_ENABLE_MEEGOTOUCHSHARE)
+NS_GENERIC_FACTORY_CONSTRUCTOR_INIT(nsExternalSharingAppService, Init)
 #endif


It would be really neat if you didn't need this Init() method.

 
+#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
+  mShareUiIf = new ShareUiInterface();
+#endif

you probably can just use this on first use.

+++ b/uriloader/exthandler/unix/nsExternalSharingAppService.cpp	Mon Oct 04 12:26:47 2010 +0100

How about making this specific to MEEGO and drop the #ifdefs inside this file?


+#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
+  delete mShareUiIf;
+#endif

You can just make mShareUiIf use nsRefPtr{} and this object will be deleted when the app service object is deleted.


+  if (!aMime.IsEmpty())
+    uri.setMimeType(QString::fromUtf16(aMime.BeginReading(), aMime.Length())); 
+  if (!aTitle.IsEmpty())
+    uri.setAttribute("title", QString::fromUtf16(aTitle.BeginReading(), aTitle.Length()));
+

Do you really have to test for emptiness?  


+  ShareUiInterface *mShareUiIf;

Please call this mShareUi.

Otherwise looks nice.

Comment 17

[Tero Turtiainen]

(In reply to comment #16)
> how is MEEGOTOUCH different than MEEGOTOUCHSHARE?  Can you ever have a
> MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

I'll check this.

> It would be really neat if you didn't need this Init() method.

I will remove it.

> +++ b/uriloader/exthandler/unix/nsExternalSharingAppService.cpp    Mon Oct 04
> 12:26:47 2010 +0100
> 
> How about making this specific to MEEGO and drop the #ifdefs inside this file?

If is already MeeGo specific on the Makefile. I was thinking that maybe some day somebody will somewhere need to implement this for some other unix-variant. But how about if I rename it to something like nsMeegoExternalSharingAppService.cpp and remove the #ifdefs.

> +#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
> +  delete mShareUiIf;
> +#endif
> 
> You can just make mShareUiIf use nsRefPtr{} and this object will be deleted
> when the app service object is deleted.

I don't understand this. I think nsRefPtr objects should implement reference counting with AddRef and Release. ShareUiInterface does not do that, as it is a MeeGo object and not Mozilla object.

> +  if (!aMime.IsEmpty())
> +    uri.setMimeType(QString::fromUtf16(aMime.BeginReading(), aMime.Length())); 
> +  if (!aTitle.IsEmpty())
> +    uri.setAttribute("title", QString::fromUtf16(aTitle.BeginReading(),
> aTitle.Length()));
> +
> 
> Do you really have to test for emptiness?  

In fact no. The end result seems to be exactly the same. Will remove the test.

Comment 18

[Doug Turner (:dougt)]

>But how about if I rename it to something like
>nsMeegoExternalSharingAppService.cpp and remove the #ifdefs.

Sounds great

> You can just make mShareUiIf use nsRefPtr{} and this object will be deleted
> when the app service object is deleted.

Sorry, I meant: nsAutoPtr

Comment 19

[Tero Turtiainen]

Attachment: Updated patch

> Can you ever have a
> MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

Ok, the current situation is that you can have Meego Touch without the sharing interface so currently this check is needed. However, this will propably change in the future. Maybe we should however now go with the current situation?

Comment 20

[Mark Finkle (:mfinkle) (use needinfo?)]

Doug - Review ping

Comment 21

[Doug Turner (:dougt)]

Comment on attachment 482447 [details] [diff] [review]
Updated patch


>+nsExternalSharingAppService::nsExternalSharingAppService()
>+  : mShareUi(NULL)

nsnull instead of NULL.

nice work!

Comment 22

[Tero Turtiainen]

(In reply to comment #21)
> >+nsExternalSharingAppService::nsExternalSharingAppService()
> >+  : mShareUi(NULL)
> 
> nsnull instead of NULL.

Will somebody land this with this nsnull fix or will I make an updated patch?

Comment 23

[Doug Turner (:dougt)]

i can push tomorrow w/ the fix.  thanks Tero

Comment 24

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/5176c8f2691e