I'm working on Xamarin iOS project. I have to load the images depends on help menu choice. I have a view controller with UIImageView and every time I'm adding the list of images I have to show a list and showing the Images. It works fine for two or three menu options (times). After few clicks app is crashing due to memory. I tried to clear the List on Close button click even though it is crashing. Can you please help me to resolve this issue.
Thanks in advance
You need to be careful with adding "heavy" resources like images. Rule of thumb:
Keep only in memory what you really need, means: clean up everything that's not in the view port. Use UICollectionViewor UITableView, they support dequeueuing reusable cells (see Xamarin docs for more information).
Clean up everything you don't need anymore. Make sure it's cleaned up for sure.
For some more information, see here: https://thomasbandt.com/xamarinios-memory-pitfalls
Related
Is there a way in a NavigationView in UWP to have multiple "Views" for NavigationViewMenuItems? The concept would be to have Categories or Folders as MenuItems, and when clicked or the NavigationViewMenuItems would slide out to the left and show the contents of the folder or category. Then when navigating back out of the folder, the folder and categories list would slide in from the left again. I know I can change the NavigationView.MenuItemsSource in C#, but I'd like to instead have this done primarily in XAML. I've tried numerous ways to do this, but can't seem to find a way that works.
I don't really have any code to demonstrate this, as this is a whole concept issue rather than a single bug that isn't working. I have searched everywhere, and have found numerous articles/links about loading different views into NavigationView.Content, but nothing of changing the MenuItems portion.
Does anyone have any ideas on how to achieve this, or a link to a tutorial I could follow? I can't imagine that this has never been done before, this seems like such a common-sense UI interface.
What you need actually is a Tree Navigator. The UWP has no such a built-in control for us. You could use the third-party control like Syncfusion TreeNavigator.
See the code sample on GitHub: https://github.com/syncfusion/uwp-demos/tree/master/Navigation
I recently inherited a Xamarin project where I am to work on the iOS project. Going over several tutorial I figured I was ready, however the person before me did not use storyboards or controllers! They did all customization of views in files named LoginScreens.cs (basically controller files from the looks of it).
For learning purposes and ease of transition I would like to get a storyboard going in this project. So I created a storyboard titled Main and added a ViewController and essential copy and pasted the view customization code used in the LoginScreen.cs into my controller.
To be a little more specific, I have a Main.Storyboard that looks like this:
Where I am using editText boxes and a button to act as place holders for what I actually do to them in the ViewController.cs.
This all seems to register and builds properly however when I run the debugger on iPhone 6s iOS 9.3 I get the following:
The changes appear to show, but all my storyboard iOS designer views remain in place. I am trying to see if there is a way to reflect the changes made in the controller on the storyboard.
TL;DR: I'm trying to alter some views in a programmatic way in my ViewController.cs file. These views were originally added via the iOS designer and for customization purposes, they were edited in the controller. I want to see the visual alteration I make on a view in the controller, reflect in the iOS designer and when I debug.
Sounds like you are trying to go from a project where views were all done programmatically to implementing storyboards. This is a Big change and will take some time to convert the views over.
In the cs file there will be things like Add(passwordTextFeild) which are going to add more views to your storyboard view, hence why you get alot of views in your login view. You wont be able to see these in the storyboard as they are done at runtime.
If you are looking for IBDesignable this is more for custom controls and you still will have to add code to be able to see the changes from the .cs file in the storyboard.
Check my Question for IBInspectable/IBDesignable in Xamarin
Check this official link: https://developer.xamarin.com/guides/ios/user_interface/designer/ios_designable_controls_walkthrough/
Probably not what you wanted to hear but the UI in iOS projects tend to be done in one of the three methods:
All programmatically
Storyboards
Xibs
There are tons of questions/blog posts (even a video), weighting up the pros and cons of each. So possibly the last developer felt it was best to do it programmatically
There is a setting, IBDesignable, that you can add to the declaration of UI classes in Swift or Objective-C. That tells Xcode the those UI objects have a custom interface that you want to be presented in Interface Builder.
I have no idea how (or even if you could) you would use IBDesignable in Xamarin/C#. If its not supported for Xamarin then you're probably out of luck.
I suggest you search on "Xamarin IBDesignable" on the net.
I'm creating an app using Xamarin Studio on a Mac.
The problem I'm facing is that a scrollview only works in the place where it was originally placed at.
I mean, I've a layout that slides to the right and left based on user input (I've two menus, one on the right and the other on the left, you get it). However, if the user doesn't open any menu the scrollview scrolls correctly, if the user does slide, it doesn't work anymore!
Here's how I'm handling the layout sliding with Xamarin.Forms:
public void toggle(){
Rectangle oldBounds = (Parent as RelativeLayout).Bounds;
oldBounds.X = -oldBounds.Width/ 3 * (_toggled?0:1);
(Parent as RelativeLayout).LayoutTo (oldBounds, 600, (_toggled?Easing.CubicOut:Easing.SpringOut));
_toggled = !_toggled;
}
Any function I might need to call? For example, forceLayout or something similar? I've tried this one and it doesn't work either!
Thanks in advance!
It may be worth considering to use the Xamarin.Forms MasterDetailPage as this has slide-out functionality inbuilt and works well, although I've experienced mixed results using an emulator in v1.2.2x, but works well on a device.
So instead of inheriting from Content Page you could inherit from MasterDetailPage and things will be easier to implement, rather than attempting to write your own.
The only downside to the current MasterDetailPage implementation in Xamarin.Forms is that the slide-out only happens from the left-hand side. This is unfortunately fixed. You couldn't even specify the fly-out to occur from the right side and also there is no support for dual slide-out areas, from the left and right sides (tested on version 1.2.3x). Chances are they will introduce possibly the slide-out direction and possibly dual-slide out areas in a later release but you would need to contact Xamarin on this as to whether its possible and the timeframe for such a feature.
In your current implementation there appears to be something getting in the way of the ScrollView that is preventing it from doing its normal action, and its not obvious what this is due to how your doing things on your page.
There are implementations of dual-sliders on Android, but I haven't looked for iOS, let alone WindowsPhone.
If you do manage to find them, you could perhaps write a custom renderer to use existing implementations to ease trying to re-create one yourself?
i managed to solve this! Check the github repository I created with an example. I included a comment on top of DetailView.cs explaining how I did it (hacky way of course! ;) ).
Basically I lay them side by side in a layout that fills all main page and than I use LayoutTo to change that layout Width so that the side menus are hidden.
Than, when you show them aka slide them in, they'll work as expected!
So, thats it, Xamarin.Forms dual panel sliding without any custom rendering!
Thanks for your help!
My team and I have recently migrated our app from Windows 8 to Windows 8.1. It worked fine until I went to update the existing pages and add a new one. Instead of any errors, just nothing happened.
The way I understand it is, in Windows 8, split pages had their information stored in a DataSource class, and I could even put all the stuff for all the split pages into the one class if I wanted to.
It's changed in Windows 8.1, though, so all the content for the pages go into the code behind pages for that actual page.
I can't actually seem to find any examples, articles or anything online on how to do this. Would anyone be able to link me to such an article or explain how the groups and items are meant to go into the class?
Thanks!
Reply to htuomola:
When I tried adding a new split page, at the time I didn't realise that how you put the content into the page is handled differently, so I just went and did the same as before. I admit, it might not be best practice to have done it like this, but at the time I felt it made the most sense. I had all the groups and items for the various split pages in the one data source class, and the individual pages just pointed to which items/groups I wanted. So, not knowing any better, I made an identical split page to the others, and it didn't pick up the new groups/items, but it did find the old ones. The old split pages were working fine at this point too. It was only when I tried to make a new 8.1 style split page, that they all stopped working and threw errors like "The type 'IME.Miscellaneous.Additional.Help' already contains a definition for 'itemDetailGrid'" and ""IMEDataSource" does not exist in the namespace "using:IME.Data".", even though I didn't change the pages that are having these errors - at all.
The Split Page item template still exists with Windows 8.1 applications even if the NavigationHelperand visual state handling code is a bit different. I think it also works pretty nicely out-of-the-box. Did you try adding a new Split Page page to you project, what problems are you facing?
Some documentation that you can find is in MSDN project templates and item templates pages. You should probably find a few samples in MSDN that use the Split Page/App template.
About the information storage, do you mean that in Windows 8.0 there was a separate view model class and 8.1 only has an ObservableDictionary property on code behind? Nothing prevents you from replacing that with a better solution. I'd just delete it and follow MVVM guidelines, setting up a ViewModelLocator and view models.
I would like to know if there is a way to manipulate an App's UI live while running?
I am not a designer and I have many problems sometimes regarding matching colours etc.
The next problem is that anytime I would like to change e.g. the colour of a control I have to quit the App then go to VS2012, apply my changes, build and execute it again to see simple changes.
I know that I see any changes in the designer but I have to see the resulting screen to get an impression of the whole.
Is there a way to achieve this?
Add a secret keypress while Debug flag is set, that raises a form and allows you to select controls and expose a property sheet for them. Be a bit of work to get right, and a good stick of code even using reflection. Might be better off with a storyboard type app to do your designing.
Unlike styles in WPF which can be dynamically adjusted (which made this type of run-time adjustment simple), there isn't as elegant of a solution for Windows Store apps. Ideally, you'd have all of your UI and colors, etc. defined in XAML files and not settable through other means (as it becomes a longer term maintenance issue).
I'd suggest just adding enough test data and configuration so that you can see the look and feel of the pages (with colors, etc.) at design-time. Blend and Visual Studio are now quite good at showing a very reasonable near final rendering of the elements of the application. It's generally not too difficult to do anymore.
One thing I've done in the past was to make a single page/form that contained all of the styles and controls in a large scroll viewer. Then, we set it so it was configurable to the be the first thing to run. The tweak/build cycle was pretty fast, and the results were still very manageable.