Switch to Mobile-Detect.json as base for gem
It would be nice if the is_tablet/is_mobile detection logic could be moved to the https://github.com/josh/useragent gem, so there's one "golden source" for this. The mobile-fu gem could then use useragent as a dependency for it's extra view template magic.
Just throwing the idea out there. @josh @benlangfeld
useragent does not claim to provide anything of the "is this mobile or not?" functionality. Currently mobile-fu relies on rack-mobile-detect for this.
Further thoughts (including from @josh) would be appreciated, but right now I'm not convinced of the benefit of this change.
May I suggest in using the logic behind Mobile_Detect class https://github.com/serbanghita/Mobile-Detect/blob/master/Mobile_Detect.json
With every release we export the new properties there. You could focus entirely on other features and leverage the detection strategy. (sounds corporate :smile: )
Any thoughts on this?
:+1: +1 for reading in the Mobile_Detect.json file. Great suggestion, much better than maintaining idiosyncratic logic inside the mobile-fu code.
@benlangfeld would you accept a PR to implement MobileDetect JSON as the base for mobile detection? Looking at their Github page seems they are widely implemented across many platforms, and I'm sure @serbanghita would advertise "Mobile-Fu" as the Ruby/Rails lib for MobileDetect (looks like there is none currently).
I already did accept this at https://github.com/benlangfeld/mobile-fu/pull/43. I've submitted a request to link back to us at https://github.com/serbanghita/Mobile-Detect/issues/236. I would accept additions to our README explaining that we use Mobile-Detect.
I think this issue is satisfied, so I'll close it for now.
Actually, now I remember our position. We're not using MobileDetect at runtime, only to assist in development of this gem. I would accept a pull request that updated us at runtime when loading the gem (not on every Rails request) as long as it had a static fallback.
(Renaming issue for clarity)
@benlangfeld I'd propose:
- we keep a copy of Mobile-Detect.json within this library, which is updated periodically by copy/paste
- we parse the file once at the time the gem is bootstrapped via Ruby's built-in JSON lib, and convert it to a frozen regex variable internally (replacing the existing regex vars)
What do you think?
I also don't think we need a static fallback (the JSON file is static). If for some reason the JSON is broken, the unit tests (Travis CI) will fail equivalently if a Ruby file was broken--in other words a .json file should be every bit as reliable as an .rb file.
Lastly, we can modify the existing Rake task from #43 so that it simply copies the file from Mobile-Detect lib and overwrites the existing file (saving us the pain of copying and pasting)
I'm happy with that as an initial step. My comments were on the assumption that we would fetch Mobile-Detect.json at runtime.
Perhaps we could do it in these steps:
- Include Mobile-Detect.json in mobile-fu, parsed at gem include time
- Allow providing an alternative Mobile-Detect.json from the application via an initializer
- Fetching Mobile-Detect.json at runtime, falling back to 2 and then 1).
I'm happy with all of your other comments.
@benlangfeld I will go ahead with this PR then.
Re: 2, I don't think there is a need for another lib here, we should encourage any fixes for devices to be raised as PRs for Mobile-Detect itself and keep it as a "golden source". That being said, from time-to-time new devices will be released and Mobile-Detect may lag behind. For this reason, we could allow users to specify a custom location from where to load their own manually edited Mobile-Detect.json file (key point being the format is "Mobile-Detect.json").
Re: 3, I personally would prefer not to fetch Mobile-Detect.json at runtime, as I like to keep everything vetted and stable (i.e. passing in Travis) in production. But if other users want it, they are welcome to raise it as a separate PR (as long as I can disable it :smile:)
Happy with your comments on 3, not essential at all.
As 2, I didn't mean any other library, I mean a Rails application itself. This way an individual application may stay more or less up to date than mobile-fu, or customise rules. Your comments are exactly what I was suggesting :) I would not accept updates to Mobile-Detect.json included in mobile-fu other than to match a release of Mobile-Detect's PHP implementation.