Market awareness of plugin/theme apps

by keyboardr » Fri, 13 May 2011 13:34:31 GMT


Sponsored Links
 It seems the Market would benefit greatly and would be much easier to
navigate if it was aware of theme/plugin applications in a
hierarchical manner.  For example: suppose I wanted to install
ADW.Launcher.  Doing a search in market, it is unclear which is the
ADW.Launcher app, and which are simply themes for the app.  Locale is
another example where it is not immediately obvious which is the app
and which are plugins.  Additionally, searching specifically for
plugins for Locale can be difficult (partly because the word 'locale'
has its own meaning).

  My proposed solution is that the Market implement a hierarchical
labeling system.  An app would default to having the "standalone"
label, but the developer would be able to label his/her app with other
apps, as well as remove the "standalone" label.  In this system, only
standalone apps would show up in general searches, and plugins for a
particular app could be seen by accessing that app's market page.
E.g., a theme for ADW.Launcher would be labeled by the developer as a
plugin for ADW.Launcher and not as a standalone app.  This theme would
not be shown in general searches, but would be seen by tapping the
"view available plugins" link on ADW.Launcher's page.  An app that has
its own functionality, e.g. Widgetsoid, but also has plugins for
Locale and Tasker would keep the "standalone" label, but also label
itself with Locale and Tasker.

  An effort should be made to prevent gaming the system by labeling
your app with a competitor's app.  Developers should be required to
opt-in to allow themselves to be a label, and should be able to unlink
themselves from apps that have used their label semi-permanently.
This way, e.g., if LauncherPro were to use ADW.Launcher's label,
ADW.Launcher's developer would be able to remove that label and
LauncherPro's developer would not be able to reapply it without
ADW.Launcher's permission.

  This system would greatly improve the cohesiveness and community
aspects of the Android ecosystem, and would allow for better
navigation and discovery for users and developers.

-- 
.



Market awareness of plugin/theme apps

by keyboardr » Fri, 13 May 2011 13:34:41 GMT


 It seems the Market would benefit greatly and would be much easier to
navigate if it was aware of theme/plugin applications in a
hierarchical manner.  For example: suppose I wanted to install
ADW.Launcher.  Doing a search in market, it is unclear which is the
ADW.Launcher app, and which are simply themes for the app.  Locale is
another example where it is not immediately obvious which is the app
and which are plugins.  Additionally, searching specifically for
plugins for Locale can be difficult (partly because the word 'locale'
has its own meaning).

  My proposed solution is that the Market implement a hierarchical
labeling system.  An app would default to having the "standalone"
label, but the developer would be able to label his/her app with other
apps, as well as remove the "standalone" label.  In this system, only
standalone apps would show up in general searches, and plugins for a
particular app could be seen by accessing that app's market page.
E.g., a theme for ADW.Launcher would be labeled by the developer as a
plugin for ADW.Launcher and not as a standalone app.  This theme would
not be shown in general searches, but would be seen by tapping the
"view available plugins" link on ADW.Launcher's page.  An app that has
its own functionality, e.g. Widgetsoid, but also has plugins for
Locale and Tasker would keep the "standalone" label, but also label
itself with Locale and Tasker.

  An effort shoudl be made to prevent gaming the system by labeling
your app with a competitior's app.  Developers should be required to
opt-in to allow themselves to be a label, and should be able to unlink
themselves from apps that have used their label semi-permanently.
This way, e.g., if LauncherPro were to use ADW.Launcher's label,
ADW.Launcher's developer would be able to remove that label and
LauncherPro's developer would not be able to reapply it without
ADW.Launcher's permission.

  This system would greatly improve the cohesiveness and community
aspects of the Android ecosystem, and would allow for better
navigation and discovery for users and developers.

-- 


Sponsored Links


Re: Market awareness of plugin/theme apps

by Tobias Eisentrager » Fri, 13 May 2011 15:09:34 GMT


 s a Locale/Tasker Plugin Developer I can see where you are coming from. You
are making good points. Specifically the linking would be great. I only see
one problem with that you do not want the plug-ins to show up on general
searches. Because the User might not be aware that the main Program even
exists.

Take my Locale Google Voice Settings
Plug-in<https://market.android.com/details?id=com.steelgirder.LocaleGoogleVoicePlugin&feature=search_result>for
example. A user who just signed up for Google voice and is new to
Android might not know that with Locale/Tasker and the Plug-in he would be
able to control his settings dynamically by location. But its very likely
that he would search for "Google
Voice"<https://market.android.com/search?q=Google+voice&so=1&c=apps>-
which could bring up the Plug-in. There he can read the description
and
find out about Locale/Tasker. I am just saying that it might happen often
that the user buys the main program just because he wants the functionality
of one specific plug-in. This could be true for Skins as well.

It would be nice to have the Market show a label that this is a plug-in so
users would understand it better. Or that you can exclude
Plug-ins explicitly if you make a search in case you are searching for the
main program. Also, every plugin could have a programmatic link to the main
program in the plug-ins description page.

The way we handle it now is that you create an Activity which reacts on the
Launch from the Market and checks in the packet manager if Locale is
installed. If it is, we launch Locale, if not we show a popup advising the
user of the main program and offering a market link to download.

On Fri, May 13, 2011 at 7:34 AM, keyboardr <keyboa...@gmail.com> wrote:


--
.



Re: Market awareness of plugin/theme apps

by keyboardr » Thu, 19 May 2011 11:09:59 GMT


 he Google Voice scenario could be fixed by applying the Google Voice
label to the plugin, but I see where you're coming from. It's a
matter of preference, but I wouldn't want to add to the complexity of
the Market UI by adding a setting to the search. Doesn't look like
that many people are really interested in the idea anyway, though, so
I don't think it'll get the attention it needs in order to be
implemented.

On May 13, 12:08am, Tobias Eisentrager <teisentrae...@googlemail.com>
wrote:

--
.



Re: Market awareness of plugin/theme apps

by Pent » Fri, 20 May 2011 18:46:27 GMT


 > Doesn't look like that many people are really interested in the idea anyway, 

As the developer of Tasker I should have a lot of interest in this
subject but I'm kindof jaded on Market issues. They're not interested
in developer feedback except when things are broke or way-out abusive,
even when there's a lot of developer concensus.

Pent

-- 
.



Other Threads

1. brannon

how do i import the android platforms into ecclipse

-- 

2. Updating SQLite from a webserver

Hi! I am starting to work with Android and SQLite and I have some
doubts regarding the database update. I have a SQLite database in my
application with a supermarket catalog. As the catalog doesn't change
a lot, I would like to update it from a webserver that I own. The
problem is that I am not really sure of how to do it with the maximum
performance.

I don't want to download the whole database because it would be too
big, I've thought of placing an xml file in the server with the
registers that have changed and the new values to download it and
parse it on the phone generating SQL queries to update, delete or
insert.

Another approach woul be updating the app but I think this would be
slower as it would download the whole database.


Any ideas?

-- 

3. Eclipse Helios and SVN problem

4. Need Some Guidance

5. Active Activity after AsyncTask

6. NullPointerException with Strange backtrace not going into my code

7. BlueTooth Serial Communication