Posts Tagged ‘functionality’
Mobile – carrier ENUM
December 17th, 2008 | 
Author: Pilot programme achieves successful traffic exchange PathFinder? brand name announced First certified vendors appointed
November 17th 2008, Macau: The GSM Association (GSMA), the global trade association for the mobile industry, and NeuStar (NYSE: NSR) a provider of clearinghouse and directory services to the global communications and Internet industry, today announced the successful completion of the pilot of their Carrier ENUM service. The service, recently branded ?PathFinder??, is now generally available to mobile and fixed network operators, carriers and related service providers.
Supported by Bharti, Lleida.net, mobilkom austria, SMART, Telekom Austria, Telecom Italia and Telenor, the PathFinder service pilot achieved an industry first by successfully exchanging international packet voice and MMS traffic enabled via a global, fully-interoperable deployment of Carrier ENUM, validating ENUM as an effective solution to IP-based routing and interconnection. The service automatically translates a phone number into an IP-based address, making it simple and transparent for users to initiate a wide range of IP-based communications via their existing phone numbers and handset address books.
“We found this trial tremendously useful in familiarising ourselves with the practicalities involved in using ENUM. Cooperation between operators is crucial in establishing how to make the telephone number a universal means to link up with IP-based applications. A simple, standardised process will benefit everyone,” said Napoleon L. Nazareno, President and CEO of Smart Communications, Inc. (SMART) and GSMA board member.
By providing mobile and fixed-line operators with a single routing mechanism, PathFinder simplifies and reduces the cost of delivery of a wide range of IP-based services to end-users. It will serve as a central ?directory? for all operators, and enables them to rapidly launch new IP services including packet voice, Instant Messaging (IM), MMS, email, and video, by facilitating the linking of an IP address to a phone number for mobile devices, fixed-line phones and IP devices.
“The successful testing of ENUM on Telekom Austria?s next generation environment demonstrates yet again that the infrastructure is ready for commercial customer pilots. With the ongoing improvement in capabilities of our global GRX/IPX platform, recently enhanced by the Carrier ENUM functionality, we are able to provide best-in-class interworking solutions for mobile network operators,” commented Boris Nemsic, CEO of Telekom Austria Group and GSMA board member.
Alex Sinclair, Chief Technology Officer of the GSMA added: “PathFinder will accelerate the rollout of innovative IP-based services that will be the key to ensuring profitability in tomorrow?s industry. PathFinder provides a one-stop solution for operators to overcome the complexity of delivering IP-based services to communications devices. Furthermore, it helps mobile operators to cut costs and leverage their greatest asset: subscriber phone numbers.”
GSMA and NeuStar also announced that Acme Packet and iXLink, a business unit of Telarix, have become the first vendors to successfully complete the PathFinder vendor certification programme, launched as part of the GSMA Industry Partner Programme earlier this year. The Partner Programme initiative is designed to foster working relationships with companies offering products and services complimentary to the PathFinder service, and provides certification of technology vendors, ensuring that PathFinder interoperability testing is available industry-wide.
Posted in Communications | 
Tags: application, business, car, Communications, Design, email, Environment, functionality, gsm association, Internet, Mac, mms, Mobile, mobile device, mobile devices, mobile industry, mobile network, mobile network operators, mobile operators, Network, service providers, Technology, technology vendors | 
Comments Closed
Faster C#
While pushing my vigilante managed code agenda I?ve run headfirst into the limitations of the Compact Framework. The CF team did a great job getting ~30% of the functionality into ~10% of the space. And with a little bit of work you can get around many of the obstacles presented by the reduced code! And hopefully this article shows you one or two ways I managed to do this.
Today?s lesson is fast bitmap manipulation. Trying to alter pixels on an image is an intensive operation due to the problems associated with accessing managed memory. It?s just plain slow. This won?t be a big concern if all you are doing is drawing an image to a graphics object ? but when you want to run a per-pixel filter on an image you quickly hit a performance bottleneck.
For this tutorial lets create a few classes that will let us invert the pixels on an image. The first thing we need to do is create a faster bitmap class. I?m going to make a class called FastBitmap, but I can?t subclass from Bitmap since it?s sealed. Oh no! Relax ? we can fix this. Let?s create a class that contains a member variable that is a bitmap.
public class FastBitmap< ?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />
{
private Bitmap image;
But with this we won?t be able to pass in our FastBitmap into methods that accept Bitmaps ? this is going to be a problem. One way to solve this is to simply pass in FastBitmap.image into the places that want a Bitmap, but this is a suboptimal solution. Instead let?s use the power of implicit casting!
public static implicit operator Image(FastBitmap bmp)
{
return bmp.image;
}
public static implicit operator Bitmap(FastBitmap bmp)
{
return bmp.image;
}
With this code we can now cast a FastBitmap object to an Image or Bitmap object on the fly. This helps especially when plugging the FastBitmap class into an existing application that is already using Bitmaps.
But we still haven?t solved our performance problems. How do we quickly manipulate the pixels on an image? Simple ? lock the pixels in memory so we can access them quickly and in a contiguous fashion. This is done via the LockBits method. I?m going to add the following methods to our FastBitmap class that allow us to put the managed pixel data into a format that is better suited for direct manipulation.
public void LockPixels()
{
LockPixels(new Rectangle(0, 0, image.Width, image.Height));
}
private void LockPixels(Rectangle area)
{
if (locked)
return;
locked = true;
bitmapData = image.LockBits(area, ImageLockMode.ReadWrite,
PixelFormat.Format24bppRgb);
IntPtr ptr = bitmapData.Scan0;
int stride = bitmapData.Stride;
int numBytes = image.Width * image.Height * 3;
rgbValues = new byte[numBytes];
Marshal.Copy(ptr, rgbValues, 0, numBytes);
}
public void UnlockPixels()
{
if (!locked)
return;
locked = false;
Marshal.Copy(rgbValues, 0, bitmapData.Scan0, image.Width * image.Height * 3);
image.UnlockBits(bitmapData);
locked = false;
}
By calling lock pixels we can copy the pixel data from memory into an array that we will manipulate later on. When we call UnlockPixels we dump this entire array back into our managed image in one atomic operation.
I?m going to ahead a few more methods to our FastBitmap class for ease of use. Here?s the completed class.
public class FastBitmap
{
private Bitmap image;
private BitmapData bitmapData;
private int height;
private int width;
private byte[] rgbValues;
bool locked = false;
public int Height
{
get
{
return this.height;
}
}
public int Width
{
get
{
return this.width;
}
}
public FastBitmap(int x, int y)
{
width = x;
height = y;
image = new Bitmap(x, y);
}
public byte[] GetAllPixels()
{
return rgbValues;
}
public void SetAllPixels(byte[] pixels)
{
rgbValues = pixels;
}
public Color GetPixel(int x, int y)
{
int blue = rgbValues[(y * image.Width + x) * 3];
int green = rgbValues[(y * image.Width + x) * 3 + 1];
int red = rgbValues[(y * image.Width + x) * 3 + 2];
return Color.FromArgb(red, green, blue);
}
public void SetPixel(int x, int y, Color cIn)
{
rgbValues[(y * image.Width + x) * 3] = cIn.B;
rgbValues[(y * image.Width + x) * 3 + 1] = cIn.G;
rgbValues[(y * image.Width + x) * 3 + 2] = cIn.R;
}
public static implicit operator Image(FastBitmap bmp)
{
return bmp.image;
}
public static implicit operator Bitmap(FastBitmap bmp)
{
return bmp.image;
}
public void LockPixels()
{
LockPixels(new Rectangle(0, 0, image.Width, image.Height));
}
private void LockPixels(Rectangle area)
{
if (locked)
return;
locked = true;
bitmapData = image.LockBits(area, ImageLockMode.ReadWrite,
PixelFormat.Format24bppRgb);
IntPtr ptr = bitmapData.Scan0;
int stride = bitmapData.Stride;
int numBytes = image.Width * image.Height * 3;
rgbValues = new byte[numBytes];
Marshal.Copy(ptr, rgbValues, 0, numBytes);
}
public void UnlockPixels()
{
if (!locked)
return;
locked = false;
Marshal.Copy(rgbValues, 0, bitmapData.Scan0, image.Width * image.Height * 3);
image.UnlockBits(bitmapData);
}
}
With the class completed we can move on to the inversion algorithm. This part is actually quite simple.
public new static void DoFilter(FastBitmap image)
{
image.LockPixels();
byte[] pixels = image.GetAllPixels();
for (int i = 0; i < pixels.Length; i++)
{
pixels[i] = (byte)(255 – pixels[i]);
}
image.SetAllPixels(pixels);
image.UnlockPixels();
}
Now we have an algorithm that in union with our FastBitmap class can invert a 320×240 image nearly instantly on a mobile device.
Thanks for reading. Let me know what you thought about this by leaving a comment!
[Author:Roshan Khan]
Posted in Windows Mobile |
Tags: algorithm, ash, bitmap image, functionality, lt xml, maps, microsoft, mobile device, mobile devices, namespace prefix, pda, performance bottleneck, suboptimal solution, unlock, Windows, Windows Mobile, xml namespace |
Comments Closed
The sad (but respectable) demise of Microsoft Spot
The trouble with predicting the future is that it’s always easy to do in retrospect. Looking back, it’s obvious that Microsoft’s Spot products were a dumb idea. The concept was that Microsoft would send small bits of wireless data — weather forecasts, stock prices, etc — to specially-equipped watches and other small devices like refrigerator magnets, which would display the information. On the face of that, it sounds kind of appealing. There are definitely people who want information like that when they’re on the go, and Microsoft had a clever plan to use some unused FM radio bandwidth to deliver the information to the devices. You’d use your PC to pick which data feeds you wanted, and Microsoft would take care of blasting it onto your watch or other device.
The problem, of course, is mobile phones. Five years ago, when Spot was announced, the handset vendors and operators were already getting hot on delivering small bits of data to mobile phones. The market for Spot, rather than being everyone who wanted data on the go, turned out to be everyone who wanted data on the go who didn’t carry a mobile phone.
In other words, almost no one.
Like I said, it’s easy to point out that problem in retrospect. But Spot was probably in development for a couple of years before it was announced, meaning it was probably started in about 2001 — before the real rise of wireless data in the US. I think someone who was paying close attention to the mobile market could have predicted Spot’s troubles. But it was much less obvious then than it is now.
Once you as a manager put people on a project and spent some money on it, it’s very easy to talk yourself into ignoring emerging signs that the product might fail. You want the thing to succeed, so you have an incentive to rationalize away any concerns. Besides, business history is full of stories about products that succeeded despite adversity and critics. How can you tell the difference between a “normal” pothole in the road, and an impassable rift?
Lessons from Spot’s demise
In the early 1990s, a number of companies developed specialized wireless modems and private wireless services for delivering data to personal computers. Internet connectivity at the time meant slow dial-up connections for most people, which could not be left active at all times. The idea of blasting data to PCs in real time seemed very attractive, and indeed the products sold well for a few years — until Internet connections became faster and didn’t require dialing out on a phone. Spot ran into the same basic process in the mobile space.
So one lesson is that when you’re potentially competing with other sorts of networks is to look very carefully at where they’ll be in three or four years.
How to manage convergence. It’s very hard to predict how “convergence” will affect a product category. Fifteen years ago many people thought it was obvious that printers would soon be built into every PC, but it never happened. Convergence seems to happen only when there is absolutely no downside to it. So you can combine a printer and scanner — or a mobile phone and a Spot watch — because there is no loss of functionality in the resulting product. But put a printer in a PC and you have to sacrifice too many things (or the PC gets too darned big).
Because a mobile phone has a larger screen than a watch, it’s actually a better data device than a watch. That should have alerted Microsoft to the danger.
Solve real problems. I’ve mentioned this before, but it’s worth repeating: Products have a much better chance of succeeding when they solve major problems for customers. Spot was cool and convenient, not life-changing. That made it much easier to absorb into some other product.
Microsoft often gets criticized by people in the tech industry for failing to innovate. According to this perspective, all Microsoft does is copy things that others have already proven. But initiatives like Spot are an exception to that rule. I wish Microsoft had chosen its battle a bit more carefully, but I respect that fact that it tried. I wish it would take more chances like this, rather than just focusing on ways to imitate the iPod and copy Google’s advertising business.
Some other commentary on Spot:
An early discussion of the technology, from InfoWorld (link)
Engadget’s article (link)
Watches vs. mobile phones (link)
Enthusiastic review in 2004 of the Tissot $750(!) Spot watch (link)
An obituary in 2006 for the discontinued Tissot Spot watch (link)
=============
By the way, I apologize for being away from the blog for so long. Family and work issues have to be my top priority, and the blog is in line after that.
Copyright 2008 Michael Mace.
Posted in Gadgets, Wireless |
Tags: blog, business, car, connectivity, fm radio, functionality, gadget, google, handset vendors, internet connectivity, Mac, microsoft, mobile market, mobile phone, mobile phones, money, personal computer, radio bandwidth, Technology, watches, weather |
Comments Closed
Mobile applications, RIP
The decline of the mobile software industry
Mobile computing is different from PC computing.
For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing’s “Zen of Palm” philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.
We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.
That’s what we all believe, but I’m starting to think we got it wrong.
Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.
It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.
The problem wasn’t just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn’t reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.
That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.
I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we’ve kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.
Elia gave me a long explanation of why. I can’t reproduce it word for word (I couldn’t write that fast), but I’ve summarized it with his permission here:
Two problems have caused a decline the mobile apps business over the last few years. First, the business has become tougher technologically. Second, marketing and sales have also become harder.
From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several — two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]
I call it three million platforms with a hundred users each (link).
The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.
Then there’s marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.
The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.
None of those avenues are available any more. Retail has gone away. The online resellers have gone from taking 20% of our revenue to taking 50-70%. The other day I went looking for the freeware sites where we used to promote, and they have disappeared. Hardware bundling has ended because carriers took that over and made it impossible for us to get on the device. Palm used to have a bonus CD and a flyer that they put in the box, where we could get promoted. The carriers shut down both of those. They do not care about vertical apps. It feels like they don’t want any apps at all.
You can read more of Elia’s commentary on his weblog (link).
Add it all up, and Elia can’t make money in mobile applications any more. As he told me, “Mike, it’s time for you to write the obituary for mobile apps.” More on that later.
Although it’s a very sad situation, if Elia’s experience were an isolated story I’d probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I’ve been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.
I’ve always had faith that eventually we would solve these problems. We’d get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody’s platform we’d get it all right.
I don’t believe that any more. I think it’s too late.
The mistake we made
We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:
A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.
Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.
In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.
But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it — if it can ever be fixed at all.
Meanwhile, there is now an alternative platform for mobile developers. It’s horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.
If you haven’t figured it out yet, I’m talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.
Think about it: If you’re creating a website, you don’t have to get permission from a carrier. You don’t have to get anything certified by anyone. You don’t have to beg for placement on the deck, and you don’t have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won’t even be aware that you exist. It’ll just be you and the user, communicating directly.
Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple’s iPhone browser, coupled with Nokia’s licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this — mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.
There are still huge problems with web apps on mobile, of course. Mobile web apps don’t work when you’re out of coverage, they’re slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.
In other words, app development on the mobile web sucks less than the alternative.
Here’s a chart to help explain the situation. Imagine that we’re giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:
This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.
Now add in mobile web development:
Based on what I’m hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.
I’m not saying all native mobile development is dead. In fact, we’re about to see the release of Apple’s native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can’t compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.
What it all means
If you’re a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That’s what Elia did, and he said it’s amazing how much easier it is to get things done. Even mobile game developers, who you’d think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).
See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.
There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can’t work effectively over the web, and it’s a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.
If you’re a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you’ll need it.
If you’re an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you’ve done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you’ve handed the game to the Google crowd.
Congratulations.
Oh, about that obituary…
In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.
Copyright 2008 Michael Mace.
Posted in Phones |
Tags: amp, apis, apple, apps, ash, Battery, BlackBerry, blog, business, business model, car, developers, functionality, game, google, iphone, Mac, microsoft, mobile application, mobile applications, mobile computers, mobile data industry, mobile developer, mobile developers, mobile development, mobile device, mobile devices, mobile ecosystem, mobile industry, mobile market, mobile operators, mobile phone, mobile platform, mobile software, mobile usage, mobile web, mobile world, money, native apps, nokia, online, operating system, palm, palm computing, palm developers, party applications, pocket pc, psi, smartphone, software stack, symbian, system, t mobile, Technology, Windows, Windows Mobile |
Comments Closed
Customizing the Sliding Panel Homescreen
Hi, my name is Jorge Peraza; I am a Developer on the Windows Mobile team that was responsible for the new ?Sliding Panel? home screen in Windows Mobile 6.1.
< ?xml:namespace prefix = o />
When we were working on the visual style and functionality of the home screen we tried to make something that looked both professional and appealing while still showcasing all the information the user is going to need to know what?s important and requires attention. While I think the default design looks really cool, we added some customization features to enable users to make it their own.
Customizing the layout:
The home screen layout can be modified using the same home.xml file from previous versions of WM, the schema of the file was extended to allow the customization of many of its elements, this includes the art assets that are used for most of the plug-ins.
When you open the SlidingPanel.home.xml file (inside \ApplicationData\Home) you will find the plug-in element that corresponds to the sliding panel home screen (its CLSID is {E9267CAB-02EE-4f37-8216-6BF6A8FF5A71}). All the child elements inside it are designed to tweak and customize the way the home screen will look.
The top level element is the plugins tag, this has one attribute called ?Order? and it?s used to list the plug-ins that will be shown and the order they are going to be laid out on the screen.
The built in plug-in names are:
1) CClock ? The big clock
2) CAppointments - The calendar plugin
3) CHome ? The notifications plugin
4) CMyPhotos ? The photos plugin
5) CMessage ? The message center (this is off by default on all sliding panel built in layouts.
6) CMusic ? The music plugin
7) Settings ? The settings plug-in
Custom Plugins ? Users can specify custom plug-ins with static content that can be displayed on the home screen.
For example, the XML snippet bellow moves the photos plug-in to the first position and enables the message center (which is turned off by default on both “Sliding Panel” and “Sliding Panel Media”)
<plugin clsid=”{E9267CAB-02EE-4f37-8216-6BF6A8FF5A71}“ name=”Bronze“ height=”266“>
<Plugins Order=”CMyPhotos;CClock;CMessage” />
</plugin>
There are many other ways of customizing the home screen using the plug-in settings like overriding the default images or even adding your own custom plug-ins that display static content, I’ll post and updated entry latter on on how to do this in detail but for now, you can use the provided home.xml files to start experimenting with this.
The notifications plug-in and message center
In the sliding panel home screen, the notifications plug-in by default serves as a dual-purpose notifications/gateway to all you phone/message accounts where every page represents one account (so, if you have multiple notifications in one category they will be shown as one summary page).
There is however an alternative behavior where individual notifications are added as independent pages (Similar to what the T-Mobile shadow home screen does) and the plug-in only shows accounts that have new notifications in them. One cool feature of this alternate behavior is that each individual notification can be dismissed without having to leave the home screen.
You can enable this alternative behavior by setting the following registry key to a value other than 2 (The actual value indicates how many pages of each notification type will be added to the home screen before collapsing them into a summary page. We have tested 2 and 5 but feel free to experiment with other values)
[HKLM\Software\Microsoft\Chome\Chome]
PageCollapseThreshold: DWORD
Note that this prevents you from being able to access the email/phone account data if there are no notifications for it. If you still want to be able to do that you can always re-enable the message center as described in the previous section as a separate plug-in.
There is one more behavioral change you can make that allows you to ?dock? the condensed view of the first plug-in to the top of the screen when it is not active, we added this for people like me that want to have the clock always visible. To enable just set the following registry key to ?1?
[HKLM\Software\Microsoft\Chome]
DockOperatorBar: DWORD
Advanced layout modification:
There are even more advanced things you can do to further tweak the look of the home screen but it is unsupported by Microsoft at this moment so you?ll have to experiment on your own J (Hint, look at the following files \windows\CHome_240x320.cpr and \windows\CHome_320x240.cpr).
Important update, please read:< ?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Posted in Windows Mobile |
Tags: 3g, amp, blog, developers, email, functionality, microsoft, mobile team, namespace prefix, pda, psi, rim, v8, Windows, Windows Mobile |
Comments Closed