Is it possible to serve a different set of client side code to the client if they are on a mobile device? I would like to offer a mobile optimized experience with my meteor app but i see no way to change the experience other than css selectors or large if/else statements in my handlebars templates, which feels very sloppy, as mobile and desktop templates and code are being served to both clients.
Is there some way that I could coax meteor into serving a different set of code to mobile clients?
Meteor is very picky about sending everything to the client, so I didn't come up with any way to prevent the client from receiving all of the templates from the server. However, I did build a package to simplify the process of displaying different templates to different clients.
It's called device-detection, and is avaliable on atmosphere (mrt add device-detection).
I've documented it on the GitHub page.
Related
Requirement
I'm am looking to host a website which contains multiple html5 games.
Similar to the Poki Games, or any other web game platform.
What I understand
I went through their (Poki Games) website and I found that multiple html5 game icons are listed on the website in a grid. And on clicking any one of the game icons, the website starts loading that particular game from an external source inside an iframe.
What I Need answer on
I want to know how they are serving multiple html5 games from another domain. Since each of the games are loaded in a iFrame I'm aware that they all have their own index.html
How to achieve the same, what approaches should I take? So that if I do
<iframe src="//another.domain.com/randomHtml5Game_1"> // will load randomHtml5Game1 game
<iframe src="//another.domain.com/randomHtml5Game_2"> // will load randomHtml5Game2 game
My skillset
I am primarily a frontend developer have experience with hosting in heroku. Also have some experience with firebase. I'll be using React along with phaser for development.
From my understanding of your question, the answer is very simple.
Just use code splitting and different render enpoints.
We would have our home page with various links to other pages (Image grid). When we click a image it changes the route.
www.domain.com/game1
www.domain.com/game2
www.domain.com/game3
You will need to code split the routes using various different ways. You could use webpack, or NextJS (Easier framework), or if your just using create-react-app, just use suspend and lazyload.
On a particular route it will load your html and javascript and run the game.
I am going to guess this isnt the answer your looking for but its a start ?
Let me know your thought ?
Daniel
Firebase supports hosting multiple sites/domains using a single Project.
You could sepparate each game into a folder and host each of them separately and with a different domain.
You can find more about it here.
I use this for example when deploying Web Apps. One domain is the app like app.appname.com then another domain www.appname.com is the landing page and if the project as an REST API I host that under api.appname.com. In my case I just use different prefixes but the whole domain and url can be different.
The benefit is that if you use other Firebase features you can shared them between all those projects. For example the authentication or databases.
I have this project where I have to code a website and ios and android apps.
I have to do this with a very limited team (basically myself). So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
I have come to consider flutter : the logic (and interaction with the backend) in dart can be compiled to both ios and android, and to javascript for the web site to call. I also like how the UI is built using flutter.
For the web site, I know there is flutter web that can be used to do a web app, but I want my website to feel like a web site more than a single page app. I have thought about using React+Gatsby to do the website's ui, while calling the dart compiled js for the logic. That would enable high page loading speed, good seo, while keeping the interactivity of a react app and the single codebase logic through dart to js compilation.
I am wondering if this seems like a good approach to you, and if not, how you would do it.
In this approach, I am wondering if it would be possible to embedded flutter web widgets inside of react js components, always in a concern of maintaining as low platform specific code as possible. I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
Update
Flutter Web is now available in a stable version for production.
Below answer is relevant back to the time when question was asked.
Flutter Web not recommended
At the current date, I would recommend not to use Flutter Web for production as it's in Beta. The Flutter Team is still working on improving quality, performance and browser compatibility. You must be cautious about using it as you may run into bugs and some other complications.
Also, I believe that the community support for Flutter Web might be on a lower side as it's pretty new.
Limited browser support
Another factor which bugs me is that the Flutter web apps can run on limited browsers as of now which would affect the reach to your user base:
Chrome (mobile & desktop)
Safari (mobile & desktop)
Edge (mobile & desktop)
Firefox (desktop)
What would I prefer?
Well, although it might be a hassle to handle different codebases for mobile and web platforms, I would still prefer to stick with React JS as it's much stable with better browser & community support as opposed to Flutter Web.
Good luck with your app! :)
I am unaware of how to use Flutter widgets inside a React app. But to address your other concerns,
So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
Given no other restrictions, this leads to a single Flutter app for both web and native. For a team as small as three we still found it easier than having multiple projects.
The key factor in merging our initial projects to one was the notion of mobile browsers. In a mobile browser you website should reduce itself to the look of your mobile app, unless they have different purposes. And this automatically happens with Flutter projects if you derive your layout breakpoints from screen size. Otherwise you would code your same narrow design twice: in Flutter for native apps and in React for web.
Same goes for native apps for tablets in landscape mode. They call for a layout that resembles your desktop browser version, and you automatically get it with Flutter.
Also in web version you may have more tools than in a native app, just because your screen allows it. Naturally, you would code this logic in JS. But then you get an order to migrate this to native apps. Would you then replace your JS logic with Dart logic compiled to JS and embedded into frames? This is a messy road.
Lastly, think of Mac, Linux and Windows platforms that will come to Flutter soon. Should you ever need a desktop native app, you would want the same layout as with web.
I want my website to feel like a web site more than a single page app.
The difference in feeling between a website and a single page app lies mostly in state management and URL handling. You may do the following to reduce it:
Introduce URLs for your pages. By default, in Flutter every piece of action can happen under a single URL of example.com/#/. The window then feels fragile as there is no URL to copy and get back to. Flutter's Router API, released in Oct 2020, allows you to generate URLs on any change in your app's state and parse the state back from URL. If you do it right, then everything on your screen becomes a function of the URL, just like in traditional websites.
Use url_stragegy package for your URLs to be example.com/path rather than example.com/#/path which immediately feels fake.
I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
No, it does not. Mostly because you get too narrow a channel of communication of messages between JS windows. How would you listen to Flutter's BLoC's stream in another frame? It would take too much boilerplate code. Also I cannot think of easy debugging process.
To me, Flutter Web still has drawbacks:
It takes awhile to load.
Many specific JS APIs are not implemented yet.
Many services you integrate with may not have Dart SDK, while having JS SDK. For instance, I struggled to get Ably working.
No search engine optimization.
You cannot use em as a screen unit, so scaling elements may get tricky.
Still with limited resources a single codebase outweights everything else.
To be clear, my team has been working on a web+native project the whole 2021. It now has passed most of the testing, but not yet released. For a sense of scale, it is a marketplace of 40+ screens.
I've got an old app I wrote in Node, Mongo, Express and Handlebars. It seems to be a bit outdated in the sense that it was more static and all data was called locally off the same domain and rendered with Handlebars on the server side, which I thought was always necessary for SEO and it wasn't built with the idea of later building and connecting the data to a mobile version.
I've been using React a lot lately as well as looking into building mobile apps and with the tutorials out there, it seems like most apps these days are designed in a way that the backend is mostly a remote api with cross site origin requests enabled and a frontend that just gets the data from it and parses it on the frontend whether it's a desktop client or a mobile client.
What would be the best way to modernize my old app that'd keep it rendering on the server side using react instead of handlebars for SEO, while also having an api service for if I were to develop a mobile version that could get and parse the data?
There's a lot of server side rending react tutorials out there, but I'm not sure what the best approach is.
To turn your current app into a SSR (server side rendered) react application would be a big ask.
You would have more luck ripping out the html / handle bars response and just returning JSON instead, effectively turning it into an API.
In terms of adding a SSR react layer, the easiest option would be to use something like Next.JS. This does the heavy lifting for you to create server side rendering. There are plenty of other options out there but Next is one of the best and probably the easiest to get going with.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
I'm doing some due diligence on backbone for a single page app and wonder if it is possible to re-use the same views/routes from the client on the server side, so that when google visits a pushstate URL, or it is accessed directly, the server can generate the exact same HTML that would be generated by backbone in the client.
It would be a pain to have to maintain two separate sets of views/routes, one on the client and one on the server. I have seen the backnode project on github however this seems to miss the point a bit and you end up having to write the same backbone router twice.
Just wondering how people are generally handling the case when using pushstate urls in backbone and needing to serve the same view from the server? Are people duplicating code or is there a better way?
I haven't tried this yet but these ideas using node.js and backbone might help:
http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
http://bennolan.com/2010/08/13/pushstate-and-nodejs.html
Basically the only way to make it so your not writing the same thing twice is to have both your node.js server and frontend client share the same routing/model code. If you are using something else on the server side (like Ruby) you would have to place node.js in front of your app server. Then make node.js proxy for new clients (push state and client js) and do actually rendering work for old/bot clients.
The other option is doing what jQuery Mobile does which is the Hijax method. The idea to make tons of HTML5 pages (you'll have to look at its routing to see).
And for completeness you should be aware of how google crawls AJAX: http://code.google.com/web/ajaxcrawling/docs/getting-started.html
This project does exactly what you are trying to do. It might interest you to check it out.
https://github.com/developmentseed/bones
I work on a team that supports a mobile web site. It's a typical web app in that it's pages of forms that submit and retrieve data from a server. Back end currently JSF.
It's working fine but there's a strong want to start leveraging more of the native device's components and features (namely messaging/alerts and UI widgets). Given the number of platforms we're trying to support (iOS, Android, BlackBerry, Symbian [yuck] and potentially Windows 7) PhoneGap seems to be the first thing I should spend some time looking at.
I think I have a good grasp on how it works (broadly speaking) in that it allows you to use HTML CSS and JS then builds a native app that 'wraps' around your code and offers up a JS API into the device's native widgets and features as needed.
What I'm not so clear on is how one would use it in a client/server type of interaction. Could we use PhoneGap to create a front end UI that would still talk live to our servers? If so, could we leverage standard AJAX/JSON/XML type technologies to send and receive the data or are there hidden hurdles I'm not aware of in doing that with a solution like PhoneGap? In otherwords, does the webview within the PhoneGap app work just as WebKit would in that we can make an AJAX call, get some data, and update the DOM?
Or is there a different type of framework I should be looking at?
A example summary explanation of what we're looking for would be: We'd like our current web application to be able to launch a native date picker on the device and receive alerts but still interact with our servers as our current mobile web site does.
As user731077 says, yes, PhoneGap can do all of that. There's a number of potential methods you could use to do so in the Javascript code of your PhoneGap app. Here's a few to check out.
XMLHttpRequest object, but I'd suggest one of the below choices that handles cross browser inconsistencies
jQuery ajax()
xui.js xhr() (my choice)
zepto.js ajax()
xui.js and zepto.js are my suggestions as they are basically stripped down versions of jQuery optimized for mobile web development. I'm partial to xui.js because its the framework commonly used by the PhoneGap guys themselves.
your every question has a YES answer :)