I had an idea, was wondering what members of the community/BUG labs thought of it
What the heck are community norms?
As the number of applications grow, so does the number of application developers. Pretty soon this number is going to explode when people start receiving their BUGs. Every developer has their own style and when faced with design decisions, often makes their own. I have been thinking this will create huge variations in application behavior, coding style, and code factoring. I think some kind of guidelines or "community norms" would help simplify matters for both developers and users.
Although constraining, a set of norms make it easier for new members of the BUG community to read the code we have put out there, since they will be somewhat similar. Application behavior norms will make the BUG more consistent for the end user, especially the novice user. We have dozens of little apps now, and we are going to get hundreds soon, somewhere in the future probably thousands. If I have 50 little utilities on my BUG, learning the quirks of every one would be a nuisance. That said, rigidly enforced guidelines will do nothing but hamper experimentation and frustrate developers - the two last things the BUG should do. I think the happy medium is a set of community agreed upon, evolving, best practices that developers can refer to. Developers will have something to look at, and if they see fit, follow the standard.
But wait? What good would guidelines do if you are encouraging developers to ignore them?
I think that most of the time developers are doing different things for lack of a standard, not because of a conscious decision to be unique. There were not enough similar applications for a clear precedent to be set. A good example of it was the naming of packages within apps. There were about 10 programs with all different schemes, I saw one I liked and made about 10 apps that followed it. Then a bunch of the newer apps followed my scheme. This has nothing to do with that scheme being best, simply it was done the most, so a pattern emerged and people followed it. I think if we consciously go out to make a good pattern it will make code reuse easier on everyone, and usability will be improved.
If your app shouldn't follow the pattern for some reason, then don't! These will only be recommendations, but why should every developer needlessly reinvent the wheel?
Okay I think this is great, but what are you talking about in practice?
Here are some topics I have in mind. This is hardly all encompassing, nor endorsed by anyone but me, nor the "right" answer because I have much less experience with software development than pretty much anyone else involved, but these were all things at one point or another I had to think about and decide what to do. They don't effect the actual functionality of my app, which means they are probably just judgment calls we should standardize.
I) Application Life Cycle
1) Starting when you app's dependencies are met vs launching from the menu
-This one is the hardest of all. If we make them launch from the menu, were is the indication that its dependencies are met? (By dependencies I mean other OSGi services and also the modules themselves.) Right now most of our apps are made for the Virtual BUG, you plug all the modules in and it pops up which is a nice easy solution. But if you have multiple apps on the virtual bug it spawns multiple windows that are not overlapped. On the real BUG they are overlapped and window management is an issue. What if i have 50 apps that need the GPS and the LCD? As soon as I stick them both in I have to hit close 49 times to get the one I want? On the other hand new users might put an app on there, stick the modules in and say "Hey, why won't the GPSAlarmClock show up?". I think it kind of depends on whether we expect people to find an app and stick 1,2, or 3 on there. Or download 50. I personally think it is more likely that people will download a lot of apps than just a few. So my vote goes for starting from the menu, but I can see both sides on this one.
2) Shutting down nicely
-John put up a good example app of how to do it correctly. As he said "there is no red square on the real BUG". Really no argument against it except that I have been using the Virtual BUG and didn't think about it.
II) Community Contribution
1) Forking vs Patching
-This is happening already, a lot of people take another person's app, make a few minor changes, and post them again. Meanwhile the original app has votes and comments and downloads so it shows up higher in Eclipse so people start downloading that one. It would probably be better to make an update, email that .jar to the original author, and have him put the upload on BUGnet than keep forking the most popular apps 2,3,4 times.
2) BUGnet Entries
-It would be good if when you posted your app to BUGnet, you filled out all the info and put a picture or logo, just that people have an idea what the app is about without downloading it. This has been done well by most, but a lot of people have ignored the licensing part, which is crucial. I have also been including in my licensing where I got the picture from and its license. Dependencies can also be indicated on BUGnet but they are via the manifest.mf file and will be automagically generated.
III) App design
1) Code style
-This isn't much of an issue since Eclipse does Java formatting for us, I would say just follow the standard Java norms
2) Package naming
-I have been breaking mine into different packages such as appname.ui appname.util appname.app and stuff like that. My main reason was to split the libraries we are using rom the application logic and from the UI, in case in the future we start using a different GUI toolkit. Also splitting the utilities off from the rest of the logic shows where there is overlap between apps, and the possiblities of creating an OSGi service the way finsprings's PositionHelper library got turned into the GPSUtilities OSGi service.
Kevin, there is some great stuff here. IMHO there are some ideas we should implement in the software, some process recommendations we can make to users, and other things that should probably be left to discretion of users. Let’s cover this in a meeting when you get back.