Check out the Go Mobile Community
A new site catering to the mobile community has been launched. It includes a web-front to a database of over 2000 mobile devices. You can also find information about how to Go Mobile in the Going Mobile 101 section. The site also includes an extensive list of device issues available for free. You also find industry links and news.
Visit компютриgomobile.tirawireless.com for more information and create an account for free.
Call me an idealist. Call me crazy. But I think technology is supposed to be used to change people’s lives for the better. I believe a good technology improves my life as a human being. Take the telephone for example. Imagine instead sending and receiving letters back and forth across the ocean. Of course every technology can be used for unethical purposes as well but what I am interested in this particular article is the initial motivation for building technology. Most particularly in the software industry.
So I went to the professionals. The ones who “did it” before. The successful ones. I read an article about a series of lectures given by established entrepreneurs in the software business, to young aspiring software entrepreneurs, all arranged by the now famous Y Combinator start-up school. I found
this article which pretty much sums up the whole thing.
After reading carefully, I found some advice on motivation. I came across this piece of advice from Max Levchin, the co-founder of PayPal:
As a final word of product development advice, Levchin encouraged founders to think about the Bible’s seven deadly sins - especially greed, sloth, envy, pride and gluttony. These characteristics, he said, describe many of the primal motivations for users.
Hmmm… Stop right here for a moment. Mr. Levchin, I was looking more for something along the lines of “what sort of technology can we build to improve people’s lives”, not “people are destroying their lives anyway, so let’s build technology that helps them do it better”. That’s ridiculous and sad, but it’s real. And what’s even more sad, it’s that it looks like this advice, was received like some sort of super secret from the masters by the young aspiring entrepreneurs.In view of this, I truly wonder what else they teach at Y Combinator.
Here’s a business idea for you:
Create a start-up school that actually teaches young techies how to use their brain power to help people conquer those deadly sins. What kind of technology can you build that helps be less greedy? What website can I join whereby I become less envious? gluck spiele onlineinternet casino pokercasino online betrugonline casino deonline casino roulettecasino spiele kostenlos spielenrussisch roulettecasino on net deblack jack online spielecasino spiele decasino online bonus ohne einzahlungno deposit casinobaccarat onlinejoyland casino bonusglucksspiele onlinespielen im casinoonline casino bonus ohne einzahlungroulette online gamegiochi casino gratisechte kasinospielekostenloses online casinoroulette tippscasino club bonusblack jack online spielenfun games roulette,funny games roulette,games rouletteonline casino paypalnew online slots,online video slots,online slotsvideo poker spielevirtual casinocasino online einzahlungcasino club roulette,casino roulette,casino roulette spielenglucks spielcasino gamblingcasino online downloadtop internet casinofaires spielenwww casino spielespiel automatencasino online guideeve online rig slotsfun games rouletterealistisches online casinoonline casino playcasino online geldonline casino no depositcasino online forumhohe auszahlungenslot maschine online spielencasino club poker bonus,casino bonus,casino no deposit bonuscasino spiele kostenlos Here’s some challenging business ideas young entrepreneurs of the 21st century. Go and think and make the right career choice. Don’t be fooled by the foolishness of quick money which you see very well where it gets you. Just look around at young rich kids who make more in a year than you and me would make in 100. Look at Hollywood. Look at rock stars. Are they happy? Are they really enjoying life?
Money should not be everything. When it becomes everything for you, you will lose in life. You will bawl your eyes for the things you missed because all you saw is the bottom line.
Hi all,
I’d like to let everyone know that we at Tira Wireless are looking for mobile developers to participate in our first ever public beta program. We’re well known for solving the difficult porting problems but with this new release we’re adding some very cool new capabilities that will help developers overcome the obstacles to getting their favorite mobile app built AND delivered into the market place.
Check it out at www.tirawireless.com
If Eclipse hangs when it tries to load your plug-in and if you see something like this in your error log:
thread "Thread [main,6,main]" timed out waiting (5000ms) for thread
"Thread [Worker-3,5,main]" to finish
then you’re probably interested in this post.
This is a somewhat known Eclipse bug and you can find more information about it here.
The problem is best described by Thomas Watson in Comment #4 in the Eclipse bug report.
The bottom line is that you should avoid doing heavy work in your plug-in start() method and instead defer the execution of any plug-in initialization code until you’re sure that the plug-in has been successfully resolved. Why? As Thomas points out, this ensures that the plug-in does not need to load any classes before it is initialized, which seems to be to root cause of the thread deadlock problem (one thread tries to initialized the plug-in and another thread tries to load a need class - but they both wait for the other to finish).
So to essentially dig yourself out of such a situation you need to listen for bundle event. To make this clearer, let’s look at an example. Let’s say your plug-in start() method looks something like this:
public void start(BundleContext context) throws Exception {
super.start(context);
myPluginInitialization();
}
If you’re trying to load classes from within your plug-in in myPluginInitialization(), then what you need to do is have your plug-in implement org.osgi.framework.SynchronousBundleListener, replace the myPluginInitialization() call from start() with context.addBundleListener(this), and implement the bundleChanged(BundleEvent event) method from SynchronousBundleListener as follows:
Bundle bundle = event.getBundle();
if (!bundle.equals(getBundle()))
return;
int type = event.getType();
switch (type) {
case BundleEvent.RESOLVED:
myPluginInitialization();
break;
}
One of the most crucial entry-level barriers to mobile software development is the wide variety of platforms. To date there are thousands of Java-enabled handsets. Large companies attempt to purchase as many devices as possible and thus cover their bases but what about the small and medium-size players?
Is buying every single device on the market an option? Clearly not.
One idea being tossed back and forth in the mobile industry is the concept of an universal emulator. That is, an emulator which would be able to emulate every single device out there. At present, device vendors such as Nokia, Motorola, and Sony Ericsson have been very good at providing free SDKs and emulators. The problems are still manifold. First of all, not every single device is supported, and the ones that are supported differ in the level of emulation accuracy compared to the actual device. In addition there is no real standard in terms of emulation, other than the Unified Emulator Interface (UEI) which is starting to pick up pace (using UEI emulators). Even if this does become the standard, we’d still have to support non-UEI emulators. Furthermore, managing all emulators from every single vendor would be a nightmare.
Here’s a proposed idea: test every single MIDP and CLDC api call on every single device
This is an almost impossible task of course. But if we did have this kind of data, and if it were always fresh and up-to-date, then we could more easily reproduce API bugs. We would essentially be aware of all KVM discrepancies in the market. We could even build a UI tool to emulate a real KVM which would thus reproducing every API bug on every device.
That’s as close as I can think of getting to the Universal Emulator idea.
With all the hype about mobile gaming, carriers and publishers are taking all the spotlight. Developers are left somewhere behind, armed with nothing more than their creativity and skills at hand. While bottom-up moves to empower developers are starting to increase (j2mepolish, eclipseme, etc) the real needs of developers are still not up on the priority lists of the movers and shakers in the industry.
Is that a problem? I think so.
After all, without developers, there’s no content. With the right amount of guidance, tools and incentives, I tend to believe a new breed of mobile developers would arise - hence the quality of the content would inherently increase. Branding does not mean higher quality apps. If indie developers were given an equal chance at distribution, mobile applications might become more adopted.
C’mon, give the little guy a break!
The Problem
There’s no easy way of getting a feel for a mobile game before actually buying it. Other than a crappy screenshot and a short description, it is the brand that sells a game, not the actual quality of it.
Idea: On-device mobile application bundle manager
Assuming the user would have the manager client installed on their device, then they could download sample 10-30 second game bundles which they would load into memory and use to get a feel of the actual game. Since in J2ME dynamic class loading is out of the question, one design choice would be to include a basic game skeleton in the client app which would act as a container for the game pack. The game bundle itself would of course have to be written according to some kind of custom language. In essence, the developer would write a short demo of their game in this custom language, add a few images (sprites, tiles, etc) then bundle everything up in some sort of binary, compressed format then publish it.
I don’t know about the killer app, but I’m more than certain that networked social apps are the way to go. The mobile device is by nature a tool for socializing. Time wasters (5-15 minute games) are surely in demand, as they represent the current ruling genre. But as far as mass distribution, I think it’s mobile networked social apps that will take the lead.
Are we ready for the jump yet?
Well yes and no. The biggest hurdle right now is networking: expensive data transfer rates, a wide variety of carrier-specific networking requirements and API’s and of course low latency. The next few years I expect to see more and more networked apps catering to wider audiences, aside from the regular under 25 male gamers.
How do you measure quality in the wireless software world?
While most of the traditional software measures still hold an significance importance (reliability, reusability, usability, etc). The quality of a wireless app tends to largely depend on the portability and usability aspects. A wireless app that runs on a limited amount of devices available on the market will have a much smaller chance of seeing the end of the distribution tunnel. Whereas a highly-portable application will definately gain faster acceptance on the publisher’s portfolio.
Furthermore, the limited user-input and display available on a mobile device represents a top measure for quality since the app usually has not more than a few minutes the impress the user and if he/she has a hard time figuring out what key or key sequence to press for a particular task, then all is lost.
While I haven’t even touched on performance and other crucial measures of a good app, I’m going to stick to my top 2 measures of quality:
1. Portability
2. Usability.
Here’s an idea about an app that would relate to a wider audience than the typical mobile gamers.
Idea: Personal relationships manager
The user would create a list of his/her close friends and family members and once in a while, he/she would rate a particular friend or family member based on certain criteria - friendliness, compassion, caring, etc. - on a scale of 1 to 10, based on events that happened during that particular day or say last few days. If the friend in question has the application as well, then the rating could go both ways. The user would then be presented with graphs representing “ups and downs” in his/her relationships.
Sounds simple? It is - that’s the point.