I'm new to UWP (windows 10), working on an app for windows phone, I wanted to know what is the difference between:
Using multiple frames and navigate from one to other.
Using a single xaml with no frames but with multiple grids (or other patterns), and instead of navigate- just change visibility so only the desired grid will be visible.
which option is better? and why?
The system keeps track of the Page you are currently on. So even when your App exists and even if it's removed from memory the OS can tell the App to reopen on that page.
Similarily when your App provides other Apps with the capability of calling into it to open certain file types of to perform certain actions (e.g. start navigation, etc.) pages will be used.
Lastly if you put everything on a single page and just manipulate visibility this will increase memory consumption of your App (as everything needs to be loaded even if it's not visible) and it also might increase load times.
Of course how much that impacts you is up to the type of App you are building. In general however I'd advice you to start building using separate pages in case your App grows. Also you get a lot of stuff out of the box if you do so (e.g. animated transitions, etc.)
Related
I am using FireBreath to create a cross browser plugin which makes use of some native libraries for the respective platform (some .NET based DLLs for Windows and Objective-C based dylibs/frameworks for Mac). Native libraries display UI screens. In order to improve usability, if the user has a multi/extended monitor setup, i would like the native UIs to appear on the same screen as the browser window is currently on.
If an identifier to the monitor with the browser window can be retrieved, that can be passed down to the native components which can be configured to display their UIs on that monitor. I have used FireBreath's getWindowPosition() method to get the rect coordinates of the plugin and used that info to identify the correct monitor in the Windows platform.
However, the coordinates returned in Mac seems to be always 0 (or 1) irrespective of monitor on which the browser window currently resides. I understand that we have to configure an event model and a drawing model in order for this to work in Mac. I have tried following event/drawing model combinations without much success.
1) Cocoa/CoreGraphics
2) Carbon/CoreGraphics
Any help in this regard is much appreciated. Also please do share if there are other approaches to achieve the same. What i want to achieve is to identify the monitor on which the current active browser window resides in Mac. I am unsure at this point, but it maybe possible to achieve this at Objective-C level (without any changes at FireBreath level). Also please note that i want to support Safari, Firefox and Chrome browsers.
You won't like this answer, but simply put you can't do that on Mac. The problem is that with CoreGraphics you are only given a CGContextRef to work with, and it doesn't know where it will be drawn. It was technically possible in older browsers to get an NSWindow by exploiting some internal implementation details, but many browsers that's no longer possible and it was never supported.
Other drawing models are the same; CoreAnimation you have a CALayer but it doesn't know which screen or monitor it is drawn to. I personally think it's a bit annoying as well, but I do not know of any way to find out which monitor your plugin is rendered to, particularly since most of them actually copy the buffer to something else and render in a different process.
I did manage to come up with a workaround and i am just replying here for the completeness of the thread. As #taxilian explained, it is not possible to retrieve plugin coordinates using the window reference. As an alternative approach, Javascript 'Window' object has 2 properties called 'screenX' and 'screenY' that return X and Y coordinates of the browser window relative to the screen. If the user has an extended monitor setup, these are the absolute coordinates with respect to the full extended screen. We can use these values to determine the monitor with the browser window (if the X coordinate is outside the bounds of the primary monitor's width, then the browser should essentially be on the extended monitor). We can retrieve DOM properties from Firebreath as explained in the following link:
http://www.firebreath.org/display/documentation/Invoking+methods+on+the+DOM
I'm building a Windows Phone application that does video capture in a page and has a custom player in another page. I'm using my own custom codec so the player needs a lot of DispatcherTimer to keep track of several behaviors on the UI part and serve the movie at the good framerate in the codec part.
I'm trying to release all DispatcherTimer as I know they are CPU intensive, but even when stopping them my app is still very slow. If I press back-back then follow the flow, the speed divides by two each time. If I don't use my player, eveything is ok. And my player is only made of 3 DispatcherTimer, a FileStream and an Image box.
I feel that DispatcherTimer are still running in memory and are double-instantiated even if they are instantiated as private on the page directly.
Can I force the page to release all this stuff?
Actually I don't understand yet what is the difference between navigating to a page next to current page, or navigating back. I don't know i.e. how the page is shown again without calling InitializeComponents, so I'm mixed up about which resources to release, and which resources to keep intact.
My execution speed problem was really caused by some running DispatcherTimer, so I'll answer it to have it archived.
The solution:
Ensuring that all DispatcherTimer has been instantiated directly on the page so that we can nullify them from anywhere in the code.
In OnNavigatedFrom, I kill the DispatcherTimer and in OnNavigatedTo, I recreate them with myDispatcherX = new DispatcherTimer();
No "temporary" timers, like "DispatcherTimer myTempTimer = new DispatcherTimer; with ((DispatcherTimer)send).Stop() in callback, as chances are that it remains in memory in an application where we navigate.
I would like to replicate the song view of the Music app, in my Windows 8 Metro app using WinJS.
I'm using a StorageDataSource to load files from the music library in a list view. This works well, now I'd like to group music files by some property (ex.: album).
StorageDataSource does not support grouping, so I'm looking for tips on how to go at this. It has to be efficient as the user can have many items in the library, but I don't need it to auto-update when new files are added/removed (though it would be nice).
My current understanding is that I need to build 2 custom data sources:
One or the itemDataSource of the ListView, and is a wrapper around StorageDataSource. Ex.: the getItemsFromIndex implementation queries the underlying dataSource for its items that it wraps in a literal. I can't just set the StorageDataSource as its objects are immutable.
One for the groupDataSource of the listView. I build it manually once when the app loads, by iterating over my first StorageDataSource and determining how many groups I have, and where each one starts in terms of itemDataSource indexes.
It works, but I wonder if there's a better way. It also seems impossible to have groups in a ListLayout and it forces items to be displayed horizontally.
Does anyone have tips for the high level view of what's required here? Thanks.
First, you are correct that if you are using a list layout that grouping isn't supported; its only supported in the Grid layout. You could choose to insert fake data items for the groups that you could style as you needed using a custom item template rendering function.
The rest of your stuff will require some learning I suggest you take a look at the ListView samples to really understand the ins and outs of the data source API.
One option is to let the ListView calculate them for you by supplying the computerDataSourceGroups function:
http://msdn.microsoft.com/en-us/library/windows/apps/hh700578.aspx
The other option is that the StorageDataSource source is right the for you to look at; adding grouping to this as a raw datasource may in fact be your most efficient and maintainable solution. It will hopefully allow you to continue to leverage the virtualization of the listview without causing the data source to de virtualized. You should find the source in the references node in VS, in ui.js.
I have a requirement that I think is common in many applications: paging. I have chosen to go with the "press to load 10 more" pattern, I think it looks better in a Metro app instead of using page numbers.
The problem I am facing is memory related. I load the first 10 items, which contain some images, and as I press "load more", I notice that the memory of the application is increased proportionally, obviously because of the images loaded. It soon gets to the 150MB memory limit where the operating system might actually kill the app.
What I am thinking is if there was some way after you scroll to the next page for the images not visible anymore to be unloaded from memory. This is gracefully handled by the iOS with the GetCell method, but is there an equivalent pattern in Windows 8 Javascript model?
Thanks,
Themos
Metro style apps usually do infinite scrolling using data virtualization. Check out the Build sessions on Data Virtualization in Metro style apps:
Build polished collection and list apps using XAML
Build data-driven collection and list apps using XAML
Build polished collection and list apps in HTML5
Build data-driven collection and list apps using ListView in HTML5
For example: HTML ListView working with data sources sample
So I'm just getting used to and getting my arms around the new "panel-based" App scheme released with the 5/5/2012 version of Rally. At first it was a bit frustrating to lose the window real estate when I've been accustomed to full-page iFrames.
I am curious however - from a desire to optimize the way I use real estate onscreen for an App page - I would like to setup and utilize a multi-panel App whose components can communicate. For instance, I'd like to have one App panel display some control widgets and perhaps an AppSDK table, and a second App panel display a chart or grid that responds to events/controls in the first panel.
I've been scanning the AppSDK docs for hints as to how this might be accomplished, but I'm coming up short. Is there a way to wire up event listeners in one App panel that respond to widget controls in another?
We have not decided the best way to have the Apps communicate yet. That is something we are still spiking out internally to find the best way to do it.
Each custom App is in an IFrame so figuring out how to make them communicate can be a bit tricky. Once we figure out a good way to do it we will be sure to let you know.
Has this topic, "app Communication", been addressed yet? I would to have one Custom Grid show User Stories. When a user story is selected another grid show the related tasks.