Extending the MoSync SDK
We love open source software and by opening up the Mosync SDK under the GPL license, we aim to give a large group of developers the opportunity to go mobile in a short time on both the Windows and OS X environments. We look forward to working together with you to create new, great applications in mobile, as well as receiving your contributions and suggestions on how to make Mosync even better!
Participation from our community is very important in the success of the MoSync Open Source project. We invite you to participate on many levels. These activities require a certain level of technical skill. As a MoSync community member, you as a user can contribute in many other ways; i.e. by participating in the forum or by blogging about MoSync on the Internet.
Share your MoSync application
We'd really like to see what people have done with the MoSync SDK, and cordially welcome everyone to share their applications. You can find some of our own application on the Example Applications page, and some of our customer's applications on the Who's Using MoSync page.
Before you can contribute code to the MoSync SDK, we need you to do a couple of things:
- You need to be able to build the MoSync SDK source using the build instructions.
- You need to sign a MoSync contributor agreement. Either scan & e-mail or fax it to us.
Send your core patches for review to firstname.lastname@example.org.
Raise an issue
How to Report an Issue
Report issues at our Jira Issue Tracker.
What follows are some additional tips on ways to make your bug report better so that someone will be able to help you.
The basics: what you did, what you wanted to happen, and what actually happened.
There are the three basic elements of a bug report, this may be only to basic but bear with us. You need to tell us exactly what you did:
"I instructed the program to draw a polygon on the canvas",
what you expected to have happen:
"I expected a red polygon to appear on the screen", and lastly what actually happened
"I got a blue circle, flickering on screen".
Always search the bug database first.
The odds are good that if you've found a problem, someone else has found it, too. If you spend a few minutes of your time making sure that you're not filing a duplicate bug, that's a few more minutes someone can spend helping to fix that bug rather than sorting out duplicate bug reports.
If you don't understand an error message, ask for help.
Don't report an error message you don't understand as a bug. There are a lot of places you can ask for help in understanding what is going on before you can claim that an error message you do not understand is a bug.
Be brief, but don't leave any important details out
This is a fine line to walk. But there are some general guidelines:
- Remember the three basics: what you did, what you expected to happen, and what happened.
- When you provide code that demonstrates the problem, it should almost never be more than ten lines long. Anything longer probably contains a lot of code that has nothing to do with the problem, which just makes it take longer to figure out the real problem. (But don't forget to make sure that your code still demonstrates the bug you're reporting and doesn't have some other problem because you've accidently trimmed out something you thought wasn't important but was!)
- If the product is crashing, include a backtrace if possible
Yes, the MoSync developer community is global and include a great many people who can speak a great many languages. But if you were to report a bug in a language other than English, many (if not most) of the people who would otherwise help you won't be able to.
Don't report bugs about old versions
Every time a new version of a MoSync product is released, many bugs are fixed. If you're using a version of a product that is more than two revisions older than the latest version, you should upgrade to the latest version to make sure the bug you are experiencing still exists. (And it's not a bad idea to try upgrading even if your version is only a version behind the most current one.)
Only report one problem in each bug report
If you have encountered two bugs that don't appear to be related, create a new bug report for each one. This makes it easier for different people to help with the different bugs.
Suggest a feature
While commercial customers and partners can influence the direction and feature set of the MoSync Mobile SDK, you can too. Submit your feature request in the issue tracker.
Write a usability report
Usability reports are feedback from the community about usage of (new) features in the real world. A usability report is a short account of the user's first impact on a newly tried feature, recording his/her expectations and the level of satisfaction achieved.
An usability report should have the following components.
- Product identification
- product name
- version used
- date of experience
- any other relevant information to identify what is being tested.
- Clarity of documentation
- Ease of use
- Real world usage
- Missing pieces
- Level of satisfaction
- (optional) Test units
These reports are like any other contribution very important to us.
Send your usability reports to email@example.com.