For those of you using SharePoint Framework solutions, how are you handling and approaching the different user experiences of the SharePoint App vs the mobile browser? Particularly for custom navigation elements in application customizers / extensions?
The biggest hurtle is custom styles for mobile navigation. In the SharePoint app, the site header experience and style is much different than the mobile browser. Are UserAgents -> "(navigator.userAgent.indexOf('iPad')"the way to go? Even so, is there a UserAgenet specified for the mobile SharePoint app?
enter image description here
Only thing that you can handle this is Responsive Layout: https://developer.microsoft.com/en-us/fabric#/styles/layout
All other things SPO does for you.
Related
We should make a decision in our company what architecture to use in new web project. We've already successfully used DevExpress' WPF components and thinking of buying their web products, but don't have enough experience with them. So, the next question is for people who have some experience with DevExpress' web components.
Could we start the solution as standard MVC project built in VS 2013 and then add DevExpress' MVC extensions such as data grid etc. and DevExtreme components (jQuery or AngularJS) as well? If we can do that, could you explain, please, what could be possible difficulties?
I think it isn't a good idea to mix up server-side DevExpress Mvc Extensions and client-side DevExtreme Widgets. If you are comfortable with asp.net mvc and want to use client-side javascript technologies, look at DevExtreme Mvc Wrappers.
It supports a convenient razor syntax to configure widgets. And you can use javascript to handle events, implement client-side templates etc.
To see how it works in action, refer DevExtreme demos.
I want to understand why client side rendering makes it bad for SEO? Are there any articles about this? Isn't the data rendering already from the server and it's just a matter of making it look like anything we want in JavaScript, how will this affect SEO?
Thank you.
The simple answer is that when you render the site with JavaScript you require JavaScript to see the page, right? Well, Google bots don't run JavaScript so in the best case they'll just see plain text.
Nothing wrong with plain text though. The most important thing is that the same info is on the page even without JavaScript.
Can you be more specific on how you planning to implement client side rendering?
Why would you like to use SEO for a SharePoint site?
SharePoint has already a very good native search engine.
Please take in count that using sharepoint as a public website is no longer recommended, furthermore Microsoft and any SP professional will discourage you from using it in that way. Microsoft has already dropped the public website feature from SharePoint Online (Office 365), and as you may know the current Microsoft strategy is “Cloud first, Mobile first” so you can expect that in the middle term most of the ways and patterns will be equivalent in SP Online and SP on-premise. So I'm not saying that you can't do this with a SharePoint server exposed to internet, however you shouldn't continue doing it, considering that you can use web services to call/get sharepoint content from any other web platform in case you need to publish some sharepoint content in a public website.
http://support.microsoft.com/en-us/kb/3027254/en-us
https://www.linkedin.com/pulse/sharepoint-public-website-platform-any-more-marwan-tarek
I am trying to build a mobile web app using worklight .I checked the IBM website but they have limited documentation on it.I wanted to know is there any inbuilt API provided by IBM in order to develop the mobile web app?
I am specifically looking for API to to control the refresh button and the back button in mobile web browser
Why limited? Where did you look? There is comprehensive user documentation and training modules in the following websites:
IBM Worklight Getting Started training modules
IBM Worklight user documentation: client-side JavaScript API reference
Regardless, there is no such thing as "controlling a browser's Back and Refresh buttons".
These buttons are provided by the mobile browser and are out of scope for whatever is running within.
It would be more beneficial for you to edit the question and explain your specific scenario - what it is that you are actually trying to accomplish.
In Worklight, you have WL.Client.reloadApp, for example, which can be used to refresh the web resources displayed. As for "back button"-like functionality, this can only be determined once you explain what you are trying to accomplish.
Additionally, keep in mind that while Worklight provides some API methods for controlling UI elements, it does so only to a certain degree and only for elements that are most common to all mobile environments (iOS, Android, ... for example, creating a tabbar); when you develop a web app for the Mobile Web environment, you cannot control via the app things like the Refresh button that the mobile browser supplies.
Lastly, you can and probably should opt to 3rd party frameworks such as jQuery Mobile and the like for the UI aspect in your Worklight application.
I have an application that will need to better support tablets in the future. I have seen some apps already created with UP1 and ExtLib Mobile Controls but I was wondering if anyone knows of specific functionality that simply is too challenging to even consider bringing to a mobile device?
For example, are there partial refresh issues on specific devices? Can managed beans still be used behind the scenes? Is dynamic content totally viable on mobile?
I'd be interested in hearing what big challenges/functions people had to give up when they mobilized their existing XPage apps.
There isn't really anything in XPages that would prevent building mobile web apps as with other web app dev models. In other words: Everything you can do with web apps on mobile you should be able to do with XPages.
XPages 8.5.3 UP1 comes with Dojo Mobile 1.6.1. However that does not prevent developers from using other frameworks like JQuery or anything else.
There are some advantages in general for native apps and hybrid apps. But personally I think most of the typically rather simple business apps can be built with mobile web apps. If you need local data/offline that might be different though.
You can use Xpages to do anything that is possible with mobile web developement. Dynamic content may not be the way to go for everything, but it will run just fine. In ITANA available for free on openntf.org, i created a simple replication engine to replicate notes tasks from the local device using sqlite to the domino server. This makes it run very fast and allows the app to run offline as well.
So i believe anything you want to try will work, you can make the Xpage output anything you want, from html, to xml, or json, to accomplish your tasks.
I know that XPages was totally incompatible with older Blackberry's. I assume that's not the case these days but back at OS 5.0 I think even buttons wouldn't work. So if you're doing anything with BB make sure it's modern and tested.
We're not really getting tablet support in ext. library until the next dojo rev I think. But there is a preview of tablet support somewhere that you can get. I've not looked yet but it was mentioned at Lotusphere. so if you want to hit tablets you might want to roll your own right now until that comes available.
Tablets are a little more challenging as the mobile controls are designed for the mobile phone size devices. That said with a little trial and error you can get a nice navigator split screen and still use the one page app mobile controls to streamline it, with records opening in their own page just like the phone version. Type ahead as I'm discovering should be handled differently if you are using the iPhone themes from oneui2.1
The oneui2.1 gives your navs and views nice styling. The forms may need a bit of custom styling.
Split your design into custom controls then you can use a server ate xpage for mobile devices and straight web. Or if you forgo the use of mobile single page controls you can always just have a seperate style sheet to accommodate the iPad. Really depends on the functionality needed. Good luck
My suggestion for anyone wanting to do tablet specific development using XPages is to move to Notes 9.0 and dojo 1.8 asap. Dojo 1.8 has an experimental control called ScreenSizeAware. This is miles ahead of anything else either the Extension Library Mobile controls or Dojo provides for Tablet development.
I'm investigating the possibility of re-using Google Apps/Docs in a local hybrid desktop/browser application.
I've been going through the Google documentation on manipulating docs, eg. the Spreadsheet. I can't seem to find any info on actually hosting the UI. Is this possible, or does it require some form of permission from Google?
You want to basically embed an browser control in your application pointed at the URL of a Google Apps doc? You could use the Google Document List API to retrieve the documents for a user, then use the URLs of those documents in your embedded browser control.
You don't need Google's permission to do that; you're writing a browser with some extra smarts built in.
What do you mean by "hosting the UI?" These apps are HTML/CSS/JavaScript. Are you thinking about embedding them in AIR or Titanium, or in some kind of web control in another app?
i briefly looked into doing this, and figured if i really wanted to i could just load the gdocs page content dynamically, and use javascript to strip away the superflous elements like header and footer. but instead i'll probably just use an OS alternate because they have come a long way and I want rich hooks.