HI
there as you can see the title what i am looking for
Global variable make app or game slow ?
Thanks
No.
I don't know why it should. Using many global variable is not a good practice, you should avoid it but it shouldn't slow your app/game.
indietab said:
HI
there as you can see the title what i am looking for
Global variable make app or game slow ?
Thanks
Click to expand...
Click to collapse
Yes they slow it because the global variables cannot be collected with the garbage collector, so the app or game becomes heavy.
The primary reason why global variables are discouraged in javascript is because, in javascript all code share a single global namespace, also javascript has implied global variables ie. variables which are not explicitly declared in local scope are automatically added to global namespace. Relying too much on global variables can result in collisions between various scripts on the same page. It is better to avoid them.
indietab said:
HI
there as you can see the title what i am looking for
Global variable make app or game slow ?
Thanks
Click to expand...
Click to collapse
You should run test to see usage of your memory, to many globals with lots of data can slow you down. You should use it for constatnts.
Keep the memory optimal, and make sure you dont have any memory leaks.
Important, you need way to see memory usage.
In short: no
However, you should avoid having large variables arrays, lists, etc. that you do not use. As the global variables will always have a reference to them, the garbage collector doesn't destroy them (as mentioned before), so they keep occupying memory unless you clear them yourself (for example by setting them to null).
If you need the functionality (and the values contained in the variables), it doesn't really matter where you define them, just know that you have to delete them (variableRef = null) if you dont need them anymore...
Have fun.
indietab said:
HI
there as you can see the title what i am looking for
Global variable make app or game slow ?
Thanks
Click to expand...
Click to collapse
I doubt it would
It's actually not possible to answer your question appropriately without more information. For example, if you have
Code:
window.x = 1;
at the beginning of your script then it won't slow anything down. If you have this though
Code:
window.x = [];
for (var i = 0; i < 999999999; i++) {
window.x.push("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
}
then that will obviously have an impact.
Also, do your variables *need* to be global, or do you not know a better way to do something, or are you just being lazy?
Context and a description would help, otherwise there's no correct answer.
Global variables could be painful about 10-15 years ago. Nowadays computing machines so fast and advanced, even if it makes slower, you won't feel it. Dont worry about your scripts, if you have got good algorythms. Visual effect and animations slow your app, think about it.
Also i advice to use Singleton class for storing globals
It's not really possible to answer this, not knowing exactly what are used as globals, but my first bet would be to say no, they won't slow down the app considerably unless you're storing "weird things" as globals. (For example, I don't think that having 10 booleans as globals would have measurable impact, it's another topic whether that would make any sense at all. Anyway, from what I know usually applications need to keep their state somehow and it's your job to figure out how to do that, using globals, singletons or whatever.) It's not going to be a good practice to overuse globals though, so I would avoid that to a degree.
More importantly you will need to learn how to detect the potential performance issues in your application: sometimes a badly written UI can cause much worse problems for sure, not to mention carelessly written networking routines etc.
Related
Hi,
I read a lot about different hardspls and radios together with different roms result in faster or slower battery drain... But nobody really knows which is the best hardspl or radio combination for any rom.
that's why I set up a little website which could help with this..
http://www.smartwebdesign.ch/ppcbatt/
It's only very simple by now.. I don't want to put real work in it until I know what you think about!
If it's beeing used I will add a search interface for sure.. but for now I just want to know what you think and if people are willing to enter data...
Suggestions are highly welcome!
Greets Chaelli
nice intention
i think you should have a required field for the location where the phone is usedand the provider(some combinations work good in some regions/orivuders)
and the first fields should be drop down ones, to be able to select previously created entries, or create a new one(to be able to sort and filter data )
le:
it would be a good ideea , for all users to use the same tool to measure battery drain in standby, and with the screen turned on at maximum brightness
this would be an emphiric way of measuring battery drainage.
if you want accurate data, then only certified people can enter data into the site.
as mentioned, there are many variables, network, age of phone, how warm it is even.
dont think its possible personally, but a good idea.
Is there any software that can do a battery of tests on WinMo? Perhaps all chefs can cook them into their Roms so that it would launch right after the initial setup before any cabs are installed and perform the tests and at the end a summary will be displayed.
thx for the feedback!
@ravest: I will add these fields but not groub by them yet (useless until there is more data) - but I will add a possibility to show the details for every device/rom/radio where you can see these things (including the comments)
@others: I also thought about measuring.. but I don't think people will take the time to measure this exactely - that's why I've chosen to use a subjective measurement - usually one has a pretty good idea how one configuration works compared to another one (with the same usage pattern - which is usally not depending on the configuration but on the person...
I know that this is not good science.. but IF we get a lot of data I think the results would be usefull...
The only way to confirm battery life is in a laboratory, with the handset linked directly to certified test equipment and kept at constant transmitter/receiver levels.
Any public database of random opinions will be much less useful than individuals trying out all the different radio/ROM's for themselves.
As others have mentioned before there are too many variables on the way people use their phones, and different networks etc etc.
@optimiser: of course you are right - but I never intended to get an exact value - but an average user-feeling. People can compare different configurations on their personal phones !usually with other variables (like usage pattern, location, provider) staying stable! - and this is what's important.. one can compare the different configurations against each other
chaelli said:
@optimiser: of course you are right - but I never intended to get an exact value - but an average user-feeling.
Click to expand...
Click to collapse
And therefore it is useless, as us humans, can't properly judge battery drain (which is measurable in mAmps) by "user feeling".
In order to measure battery drain you would need to set up a test procedure, which must include (beside the others) the following:
the same phone
the same period of time
same usage
and WORKING measurement tool. Not a software (because they tend to swtich of on standby mode) but plugged external measurement.
THEN you could approach some kind of fair measurement. Otherwise it's "how you feel", and as long as you are happy with your feelings, it's perfectly OK.
Cheers.
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
Seeing as WP7 will be almost as crippled as the iPhone, let's see ways in which it will be better, besides replaceable battery and memory card(and it's not certain every OEM will follow up on those either). So far it has two weaknesses that only the iPhone has: Lack of multitasking and apps must go through the marketplace.
In order to pick up iPhone users it will have to offer some advantage that the average iPhoner will notice.
Some advantages:
Information at a glance a la today screen with the hubs. iPhone has nothing like this.
It will (supposedly) have some degree of multitasking.
Two more hardware buttons.
Its funny since I've had my HD2 I've not really used multitasking and when I had my iPhone only not being able to use Spotify in the background bugged me so maybe certainly for me multitasking isn't a be all and end all.
Having read lots of stuff about WP7S, the conclusion I have come to is this...
There will be two types of apps
1. Apps with no need to run in the background
2. Apps that do need to run in the background
Examples of type 1 are games, spreadsheets and word processors.
Examples of type 2 are IM apps like palringo, and music streaming services such as pandora.
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive.
That's my take on what's going to happen, and we'll see if I'm right at MIX 2010 next month.
So your answer is - yes it will multitask but only when it is truly needed. Which to me is the best of both worlds. It will ensure a smooth user experience whilst still allowing background operations.
Jim Coleman said:
In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Click to expand...
Click to collapse
Lets hope theyre not too stingy with giving out access to these API's!
The hubs/services (I'm not sure what MS is calling these) system looks good; getting new relative options available on multiple hubs just from installing a single app (like they demo'd with Facebook) should make all the apps work together much better than on an iPhone. I already want to try to make one to generate a music playlist based on past plays, and another to find lyrics to the currently playing song; If I understand the system properly, these would automatically integrate into any 3rd party apps using the appropriate media API's.
Also the context-sensitive search looks to be awesome.
One disadvantage: possible lack of native code execution and probably no OpenGL support - making it harder for iPhone app developers to port their existing apps to Windows Phone.
weesals said:
One disadvantage: possible lack of native code execution and probably no OpenGL support - making it harder for iPhone app developers to port their existing apps to Windows Phone.
Click to expand...
Click to collapse
why the heck should iPhone devs have an easy migration to WP7 if WM 6 devs don't?
weesals said:
Lets hope theyre not too stingy with giving out access to these API's!
Click to expand...
Click to collapse
The impression I'm getting so far is that they will be very stingy indeed. The only people who will ever get access to non-standard API's will be phone manufacturers and networks, and even they usually won't get access to the native API's most of the time. Microsoft will not publish any documentation about native API's. To get access to them the manufacturers will have to apply to Microsoft on a case by case basis. If Microsoft judges that a native API is required (and if there actually is one that might help) then only at that point will they release any information, and a condition of this is that they will vet the resulting piece of software to verify that the native API is being used correctly, and forbid the release of the software if it isn't.
What we don't know yet is where multi-tasking sits within all this. Is it a standard managed API, an extended managed API, or a native API?
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
The only thing I like about iPhone is how I use the virtual keyboard to type text.
I have tested HD2 and iPhone in a store, and from my own perspective, iPhone is more responsive and accurate compared to HD2.
I hope WP7 can be better than those 2 platforms in this task.
giggles33 said:
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
Click to expand...
Click to collapse
gogol said:
The only thing I like about iPhone is how I use the virtual keyboard to type text.
I have tested HD2 and iPhone in a store, and from my own perspective, iPhone is more responsive and accurate compared to HD2.
I hope WP7 can be better than those 2 platforms in this task.
Click to expand...
Click to collapse
that isnt aways based on the OS or software, but the quality of the touch screen.
Jim Coleman said:
Having read lots of stuff about WP7S, the conclusion I have come to is this...
Click to expand...
Click to collapse
This definitely seems like the best thing to do for multitasking in WP7.
We are going to need a task manager though...
As for comparing to the iPhone:
-WP7 will be available in different hardware configurations, giving the consumer a choice in the style and capability of their device.
-Xbox integration, which will most likely include Arcade games (ported for playability of touchscreens)
-Better hardware standards
-Not quite as locked down (hopefully)
RAMMANN said:
why the heck should iPhone devs have an easy migration to WP7 if WM 6 devs don't?
Click to expand...
Click to collapse
Because that's where the money is.
Seems people are struggling to come up with any, maybe something magical will appear in the next few weeks, although I doubt it, the advantages of WM seem like they will be gone with WP7, people on forums like this and blogs have been asking for a windows mobile iphone [without being an iphone] and it looks like they're going to heed the demand.
The most important advantages are gone.
They've made an exact copy and think it is enough. But it's not. When you try to catch up, you have to be better.
There's almost nothing WP7 is better at. It's an exact copy of iPhone OS with a better UI on top, but lacking the thousands of applications. That's not going to be enough and I really can't think about a reason why consumers and developers would be excited about this.
(and don't get me wrong - I LOVE the UI - it's just not enough)
Free Microsoft Office (Document viewing, creation, downloading, and editing)
Abobe Flash Player 10.1 is coming
File downloads (possibly)
Apps like a Wi-Fi router and file manager will likely come and be allowed
XBOX LIVE! Enough said.
Zune integration and support (I'm a Zune user)
1GHz Snapdragon is the processor minimum (This will lead to awesome apps and games)
WVGA display minimum (You might not care too much about this one, but I've seen the difference, and it's AMAZING!)
Bing search (That's just my preference.)
Contextual search (A handy feature, I suppose.)
There is not an app collection of 100,000 with most of which being totally useless. This means that you"ll be able to find the good apps.
Even if Microsoft won't allow apps like a Wi-Fi router and file manager, all we would need to do would be to get all WinPhone7 users on XDA to install the XNA Game Studio (and possibly the Win Phone7 SDK) and we could simply upload .ccgame files to XDA instead of .cab files.
giggles33 said:
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
Click to expand...
Click to collapse
I know! Why must smartphones always be compared to a simple feature phone! I've tried the iPhone/ iPod touch (3rd generation) at Best Buy stores, and, let's just say, they froze more and gave out more errors in 5 sec. than 5 WinMo devices did combined over the course of 2 hours. The iPhone's keyboard isn't too great either. It's (the errors thing) 100% true.
Jim Coleman said:
There will be two types of apps
1. Apps with no need to run in the background
2. Apps that do need to run in the background
Examples of type 1 are games, spreadsheets and word processors.
Examples of type 2 are IM apps like palringo, and music streaming services such as pandora.
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive..
Click to expand...
Click to collapse
This is the right answer. Anybody who calms down would see that this makes sense. More Apple-like approval process for Type 2, free reign for Type 1
Shasarak said:
The impression I'm getting so far is that they will be very stingy indeed. The only people who will ever get access to non-standard API's will be phone manufacturers and networks, and even they usually won't get access to the native API's most of the time.
What we don't know yet is where multi-tasking sits within all this. Is it a standard managed API, an extended managed API, or a native API?
Click to expand...
Click to collapse
Yeah, you're talking about native vs managed stuff, which is not the same as simply allowing an app to have a background process. True, AT&T and HTC will have to apply to for native API use for stuff relating to making calls, etc, but that was only about OEMS and network operators.
Regular 3rd party guys, of which there are many, will be expected to get a way to do what they need on the device. Pandora we've seen in Music, you can expect apps like Palringo showing up in People
burnblue said:
This is the right answer. Anybody who calms down would see that this makes sense. More Apple-like approval process for Type 2, free reign for Type 1
Click to expand...
Click to collapse
Just because it makes sense doesn't mean Microsoft will act like that. In fact, I'm sure they will not.
The mass market will not benefit from every joe having all the API's because it's going make programs that cause glitches/crashes/memory leaks, etc. They are doing what they think is best for mass market and that is make sure things work well on the device and everything is user friendly with the least amount of hiccups possible. So that means more restrictions on us.
^^^ +1
Jim Coleman said:
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive.
That's my take on what's going to happen, and we'll see if I'm right at MIX 2010 next month.
So your answer is - yes it will multitask but only when it is truly needed. Which to me is the best of both worlds. It will ensure a smooth user experience whilst still allowing background operations.
Click to expand...
Click to collapse
This neither solves problems nor guarantees anything though. Poor code is still poor code. Too many apps running is STILL too many apps running (slows the UI). MS can police neither. So, your #2 solution really makes no sense and has no advantages. MS has no way of predicting who will run what app and when on their phones. What if a user chooses to run several "Type 2" apps? Will you get some sort of error message? Will the MS police arrest you for ruining the UI experience? What happens after several years of approved type 2 apps hitting the market? Now were back to the same problems of WM.
Dude, we're talking about 1Ghz+, 512MB+ RAM phones here! You can run lots of apps without slowing anything down. Really, the "multitasking slows down the UI" argument is utter bull****. A good OS handles multitasking in a way that doesn't slow down anything. Restrictions are only necessary if the OS itself sucks. A good OS doesn't need them.
So, with WP7, we lose all support for the .cab and associated API as it exists now. Replacing it is the .xab format.
What's a .xap?
A .xap is a simple, every day .zip file, renamed to .xap. Inside, it contains the app and all relevant dependencies. There are a number of possible .xml files that could be included inside the .xap to determine things like required security access level, to tell the system which .dll contains the main() for the application, etc.
I believe the .zip also provides a container for the virtual filesystem available to the app (not sure on that, it may be stored in a separate container, have to analyze more)
At least initially, .xaps will only be available for deployment through the Marketplace.
Regarding preloaded applications by OEM/MO: Requirements are much more strict in this regard now due to frequent end-user complaints about "slow, laggy, etc" Stock ROMs. I know every one of you reading this knows what I mean Preloaded App Requirements (which will be distributed as .xap) as follows:
Maximum of 6 preloaded applications on the device, not to exceed 60MB
All preloaded apps must pass Marketplace submission process (some extended APIs are available to OEM/MO so the process is slightly relaxed in that regard)
The application(s) and all future updates must be free of charge.
The apps must launch without dependency on network availability.
The apps must persist through a "hard reset".
The apps must be updatable and revocable (!!!!) through the Marketplace.
The apps must notify the user at first launch of any capabilities to be utilized and get user consent (to access compass, accelerometer, network, etc.)
I've attached a .xap to this post for your examination. It's renamed to .zip for the attachment system to allow it.
Hehe.. this reminds of the "widgets" for Vista and 7 or the "apk"s for Android. Same stuff it sounds like Thanks for the info master Da_G
Does this mean .cab.pkgs are being changed too?
The .cab.pkg format remains intact for imageupdate (actually I haven't examined it in depth just yet, but all indications are that they have not changed .cab.pkg format)
Bump for visibility
Interesting...Wonder if there will be a process to convert some cabs to xabs.
Highly unlikely. xab's are silverlight applications meaning you have to use xaml , c# code and libabries all in one small zipped file. Cab's are Cabinent files that has an inf file that specifes what libabries and files are going to be enclosed in the file. To put it simply a xab is a standalone application that does not require extraction or installation to run and a cab is an application which requires an extraction and for its contents to be placed in specific areas in order for the dependents to find and use them.
Also to clarify. Local storage for xab's are not defined or stored in the xab file. they are defined by the silverlight runtimes which is handled by the os. As of now since there is little information as to how the windows phone internal structure is (apart from us knowing that windows phone will utilised microsoft unified storage.). on windows 7 and windws vista after u install the silverliht runtimes all xab's that request local storage is stored in <SYSTEMDRIVE>\Users\<user>\AppData\LocalLow\Microsoft\Silverlight\is .. Just note silverlight local storage works just like flash local storage. the only exception so far for windows phone is that u will not be able to access a lot of local directories just predefined stuff like music, pictures and documents.
Just before people get into bad habits; they are xap, not xab files. No relationship to cabs whatsoever save as a container format.
Da_G said:
Regarding preloaded applications by OEM/MO: Requirements are much more strict in this regard now due to frequent end-user complaints about "slow, laggy, etc" Stock ROMs. I know every one of you reading this knows what I mean Preloaded App Requirements (which will be distributed as .xap) as follows:
[*]Maximum of 6 preloaded applications on the device, not to exceed 60MB
Click to expand...
Click to collapse
That is just brain damaged. Pre-loaded apps add clutter, but they also cut down on cost. Choose your poison. Pre-loading has little to do with with speed penalties, when done properly. Frankly, if roms have the same ancient architecture under WM7, then Microsoft really needs some technical leadership replaced.
[*]All preloaded apps must pass Marketplace submission process (some extended APIs are available to OEM/MO so the process is slightly relaxed in that regard)
Click to expand...
Click to collapse
Now this is where some quality review comes in. It all depends on how good the standards are, and I dare say they will seem lower and lower as time passes. Hell, they're already admitting that OEMs will have relaxed standards.
[*]The application(s) and all future updates must be free of charge.
Click to expand...
Click to collapse
That's just silly. You'll get a bunch of lite software versions with next to zero shelf life instead of upgradable versions with marginal shelf life.
[*]The apps must launch without dependency on network availability.
Click to expand...
Click to collapse
what does this even mean? Does that mean no internet based app can be installed? All it really means is you have to quit gracefully if the network isn't available.
[*]The apps must persist through a "hard reset".
Click to expand...
Click to collapse
This is a good thing, but primarily a reflection of back when flash memory was in short supply. Haven't run into it in forever.
[*]The apps must be updatable and revocable (!!!!) through the Marketplace.
Click to expand...
Click to collapse
Well, updateable is good...but revocable? Maybe removable would be more consumer friendly. Makes me think of the PS3.
[*]The apps must notify the user at first launch of any capabilities to be utilized and get user consent (to access compass, accelerometer, network, etc.)
Click to expand...
Click to collapse
What I take from all of this is that
a) they want to drive more traffic through the marketplace.
b) they want to drive more traffic through Windows Certification
Good for the average consumer, great for Microsoft. Personally, the only point that has any value to me at all is a central marketplace. The rest of the bullets are ways for Microsoft to drive seperation between their brand name and many software vendor's crappy products.
ahhhha , sound interesting .
gguruusa said:
That is just brain damaged. Pre-loaded apps add clutter, but they also cut down on cost. Choose your poison. Pre-loading has little to do with with speed penalties, when done properly. Frankly, if roms have the same ancient architecture under WM7, then Microsoft really needs some technical leadership replaced.
Click to expand...
Click to collapse
I don't know, I wish MS enforced that same restriction on the Desktops OSes too. Nothing worse than getting a Dell or Sony PC full of preloaded gunk.
gguruusa said:
That's just silly. You'll get a bunch of lite software versions with next to zero shelf life instead of upgradable versions with marginal shelf life.
Click to expand...
Click to collapse
It's a big leap to come to that conclusion seeing as most software that ships with phone doesn't have additional charges. The restriction as I read it really means you just won't get a tonne of unwanted trial-ware on you shiny new phone.
Eoinoc said:
I don't know, I wish MS enforced that same restriction on the Desktops OSes too. Nothing worse than getting a Dell or Sony PC full of preloaded gunk.
Click to expand...
Click to collapse
maybe, but that same preloaded gunk cut the price of your dell and sony. While I don't like preloaded gunk, I don't like expense either. What I do like is being able to make the decision myself of how much gunk vs expense I am willing to tolerate.
It's a big leap to come to that conclusion seeing as most software that ships with phone doesn't have additional charges. The restriction as I read it really means you just won't get a tonne of unwanted trial-ware on you shiny new phone.
Click to expand...
Click to collapse
I agree it is target at no trial-ware. Any idea how people in the business world get around that? Lite versions of software (aka cripple-ware). Pay per use software. I'm sure there are other strategies. Frankly, if they enforce the ability to remove, I'm not that particular on how much gets pre-loaded. The fact of the matter is that the problem isn't how much crap comes with your phone; it is that you don't get to pick whether it is installed.
great find Da_G, so its XAB no more cabs
the0ne said:
great find Da_G, so its XAB no more cabs
Click to expand...
Click to collapse
XaB no.
XaP
tighoor said:
XaB no.
XaP
Click to expand...
Click to collapse
oops ..
How bad this is for the guys that dev here?
or... how good?
guessing .xap is short for XNA Application Package ?
vladimir2989 said:
guessing .xap is short for XNA Application Package ?
Click to expand...
Click to collapse
close, but no. In fact, it's actually a silverlight application package - it's been used for web stuff since silverlight released.
how to convert XAP to OEM/EXT package ?
I'm not sure what you mean by "OEM/EXT" package, but it's probably not possible. If you want to include an app with the phone, that *is* possible but the only way I know of is to include the XAPs in the ROM and then install them on first bootup. Probably not the best approach.
I have a PhoneGap application designed to work on multiple mobile platforms. I'm loading a dynamic HTML content from an external page on the Internet using jQuery Mobile. The problematic system is Windows Phone 7.
This is what I get from the external page, with the URL of the script tag already replaced to load from the phone instead of from the net to save bandwidth:
HTML:
<script type="text/javascript" charset="utf-8" src="x-wmapp1:/app/www/test.js"></script>
This works fine on Android, iPhone and even BlackBerry when I replaced the x-wmapp1: part by a respective counterpart (e.g. file:///android_asset/www/ on Android). However, on Windows Phone 7 it doesn't seem to work at all.
When I try to load the same URL via $.getScript function, it always returns a 404 eror, even if I try and load it with a relative path only.
Any suggestions?
First of all, this type of question may be better suited to the Software Development or Apps and Games sub-forums, as a lot of the people who hang out here are more familiar with homebrew hacks. I'll give it a shot, though.
First of all, what kind of path are you trying to use? I haven't tried loading scripts or images in HTML or JS, but to dynamically load content within the app itself typically requires some care with regard to the path. For example, is the JS file being built into the assembly (as a resource) or included alongside it (as content)? How about the HTML page?
This is a kind of lame approach, but one option that's sure to work is just inlining the scripts in the page, directly. That won't increase the total app size or load time at all, although it might make maintaining the app take a little bit more effort.
Thanks for the reply, I will try to post this into the more appropriate forum.
With regards to paths - you can see the path in the HTML snippet I provided in the original question. It's all a bit specific and we cannot afford to load JS directly from page, since that does increase the size of the resulting HTML, sent from an external PHP page, thus increasing bandwidth. This is the first reason why we chose to have all JS and CSS files directly bundled with the application and load them internally rather than from Internet.
Also, all of JS files are included alongside the application as content. I'm using the same approach for all images, since if they were included as a resource, they would not show in the application.
GoodDayToDie said:
First of all, this type of question may be better suited to the Software Development or Apps and Games sub-forums, as a lot of the people who hang out here are more familiar with homebrew hacks. I'll give it a shot, though.
First of all, what kind of path are you trying to use? I haven't tried loading scripts or images in HTML or JS, but to dynamically load content within the app itself typically requires some care with regard to the path. For example, is the JS file being built into the assembly (as a resource) or included alongside it (as content)? How about the HTML page?
This is a kind of lame approach, but one option that's sure to work is just inlining the scripts in the page, directly. That won't increase the total app size or load time at all, although it might make maintaining the app take a little bit more effort.
Click to expand...
Click to collapse
First question: have you set the IsScriptEnabled proerty on the control to True? It defaults to False, preventing scripting within the control. Also, changing it only takes effect
on navigation, so if you already loaded the page and then set this property, it still won't work.
Anyhow, I missed that your HTML was coming externally, and only the scripts and stylesheets were local. That's... interesting, and seems reasonable enough, and I can't find any info online that exactly matches your use case. The way you're structuring the script src URI looks weird to me, but I haven't messed with the WebBrowserControl very much at all.
One solution, though a bit hacky:
Use the WebBrowserControl's InvokeScript function to dynamically load scripts into your pages. To do this, you would first need to load the script file content into a .NET String object. The GetResourceStream function is probably your best friend here, combined with ReadToEnd(). Then, just invoke the eval() JS function, which should be built-in, and pass it the JS file content. That will load the JS into the web page, creating objects (including functions) and executing instructions as the files are eval()ed.
Of course, you'd need to do this on every page navigation, but you can actually automate it such that the page itself requests that the app load those scripts. In your app, bind the script-loading function to the ScriptNotify event handler, probably with some parameter such as the name of the script to load. Then, on each page served from your server to the app, instead of including standard <script src=...> tags, use <script>window.external.notify('load localscript1.js')</script> and so on; this will trigger the app's ScriptNotify function for you.
I hope that helps. I can see your use case, but somewhat surprisingly, I couldn't find anybody else online who had either run into your problem or written a tutorial on doing it your way.
Thank you for your reply, it was very informative. One question though - why do you think the way I'm structuring the SCRIPT URI is wierd? I tried to mess around with relative URIs and the such, however those would load the JavaScript file from Internet rather than from the application itself.
The problem I'm running into with your proposed solutions, however is that:
1. the project is a PhoneGap/Cordova application, using its own components, so I have no idea where I would look for IsScriptEnabled here (although this all worked on an older PhoneGap release, so I'm guessing they have it set up correctly)
2. injecting a script programmatically on each navigation would require me to rewrite much of the code we already use for other platforms, not to mention those custom Cordova components, which I don't even know if they can handle such thing
As for my user case - I was surprised to be the only guy on the internet with this methodology in place as well. So it either works for everyone else or nobody really thought of doing it my way, since it's basically an Internet application (maybe the don't want to disclose their sources, who knows).
CyberGhost636 said:
1. the project is a PhoneGap/Cordova application, using its own components, so I have no idea where I would look for IsScriptEnabled here (although this all worked on an older PhoneGap release, so I'm guessing they have it set up correctly)
Click to expand...
Click to collapse
In the WebBrowser properties.
CyberGhost636 said:
As for my user case - I was surprised to be the only guy on the internet with this methodology in place as well.
Click to expand...
Click to collapse
Of course you not "the only guy". I've tried to port/run a few HTML java-script based games on WP7 (Digger and couple more) more then year ago; they runs well with one HUGE exception - touch screen events are freezing scripts execution and make games not playable.
The "x-wmapp1:" URI scheme was what I was referring to. Not sure where that comes from, but I haven't done anything really with the WebBrowser control.
I have no knowledge of PhoneGap or Cordova; I assume they're "we write your app for you" frameworks? One would assume that such tools would know to set IsScriptEnabled, but you may have to do so manually. A bit of web searching on that direction may be fruitful - maybe earlier versions enabled scripting by default, and now it's disabled by default so you have to specify an option somewhere?
Injecting the script on navigation really doesn't require any major change to the server-side code. I mean, is sending
<script>window.external.notify('load localscript1.js')</script>
really much different from sending
<script type="text/javascript" charset="utf-8" src="x-wmapp1:/app/www/test.js"></script>
? If that's too different, you could instead send
<script src="http://yourserver.com/LoadLocalScripts.js"></script>
and put "LoadLocalScripts.js" on your server with the following code:
window.external.notify('load localscript1.js');
This has only a trivial increase in server traffic and load time, but lets you continue using external scripts instead of inline ones. Very little server-side change needed at all.
Now, the additional client-side code to support the window.external.notify and call InvokeScript... normally I'd say that's dead easy, because it is if you have any experience with the .NET framework, but in your case I get the feeling that this isn't so? I code to the framework, or to the underlying native code, and I tend to code "raw" (very little auto-generated code), so I'm not going to be able to help you solve the problems with a "make me an app" wizard unless I can see the code it generates for you.
For what it's worth, here's the approximate raw code that I'd use (it's over-simplified, but close enough):
void HandleNotify (String param) {
String[] parts = param.split(" ");
if (parts[0] == "load") LoadScript(parts[1]);
}
void LoadScript (String script) {
String content = Application.GetResourceStream(new Uri(script, UriType.Absolute)).ReadToEnd();
theBrowserControl.InvokeScript("eval", content);
}
void theBrowserControl_Loaded (...event handler args here...) {
theBrowserControl.IsScriptEnabled = true;
theBrowserControl.ScriptNotify += HandleNotify;
theBrowserControl.Navigate("http://yoursite.com");
}
the URI comes from Windows Phone itself, with this code, you can see for yourself:
var a = document.createElement('a');
a.setAttribute('href', '.');
alert(a.href);
also, I've been informed that this works in Cordova 2.0, so it might be a 1.8.1 bug... will try and see how it goes
thanks for your help so far!
Looks like it was a problem with PhoneGap 1.8.1 - after upgading to Cordova 2.0 (PhoneGap got renamed) it all works now... thanks for all the help!