- How do I install torann/device-view in a Laravel app?
- Run composer require torann/device-view:0.0.4, pinning the exact version rather than using a caret on a 0.0.x line. Because the package predates auto-discovery, add Torann\DeviceView\DeviceViewServiceProvider to the providers array in config/app.php manually. Then publish the config with php artisan vendor:publish and review the device-to-suffix mapping. Verify the view finder resolves a device path before rolling it out anywhere.
- Which Laravel versions does torann/device-view support?
- The package targets Laravel 5.4, and its last release existed solely to declare that constraint. It will not float onto Laravel 5.5 or later because the version line is pinned at 0.0.x. If your app runs Laravel 6 or newer, do not adopt it; vendor the pattern behind your own interface instead. On a 5.5+ upgrade, remove the manual provider entry in the same commit to avoid double registration.
- How does device-view decide which Blade view to render?
- It decorates Laravel's view finder and wraps a user-agent classifier that sorts each request into mobile, tablet, or desktop. A call such as view('pages.home') is rewritten to a device-suffixed variant like pages.mobile.home before the finder returns a path. That keeps the branching out of controllers, routes, and middleware, and lets a single URL serve divergent Blade markup.
- What happens when a device-specific view file does not exist?
- Resolution degrades gracefully to the base desktop view, so missing variants do not throw an exception. That is convenient in development but dangerous in production, because a broken mobile layout becomes a screenshot rather than a pageable error. Treat silent fallback as the primary failure mode to monitor, and add your own logging or assertions if you depend on variant coverage.
- Is torann/device-view still maintained?
- No. The last release was January 2017, the repository has around 14 stars and zero dependents, and there is a single maintainer with no visible CI or deprecation policy. It is best treated as a legacy-estate artifact rather than a living dependency. The BSD-2-Clause license does permit vendoring the roughly 100 lines you need, provided you retain the license notice, and that is the recommended default.
- Does torann/device-view work with php artisan config:cache?
- You must prove it does before adopting. Packages of this vintage routinely call env() outside config files, which works locally and then breaks in a cached production deploy. Run php artisan config:cache and re-test view resolution under the cached configuration. Make that check part of your acceptance criteria, not an afterthought.
- How can I test that device detection is working correctly?
- Call app('view')->getFinder()->find('welcome'), record the absolute path it returns, then spoof an iPhone user agent and confirm the path changes. Repeat the same check after running php artisan config:cache to catch cached-config regressions. For tablet coverage, test against an iPadOS Safari user agent specifically, since it may be classified as desktop. Keep these checks in an automated test so a future provider change cannot silently break resolution.
- Is device-view safe for SEO and CDN caching?
- Same URL, different HTML is the core risk. If your CDN keys on URL alone it will serve the wrong markup to the wrong device, which is actively harmful. You need Vary: User-Agent support and device-aware cache keys, plus an explicit SEO sign-off on mobile-first indexing implications. Without that infrastructure, responsive CSS is the safer answer.
- Should I use device-view or responsive CSS?
- Use responsive CSS when the mobile delta is a handful of CSS classes or a rearranged layout. It caches better, is simpler to test, and avoids user-agent classification problems entirely. Adopt device-specific views only when the mobile and desktop template sets genuinely diverge in structure and content. That responsive-versus-device-specific decision is the real question; everything else follows from it.
- What are alternatives to torann/device-view?
- The strongest alternative is building or vendoring the capability yourself behind an internal DeviceViewResolver interface exposing device() and view() methods. Bind it in AppServiceProvider and delegate to the package initially, so replacement becomes a one-file change. Mobile Detect and similar UA libraries cover classification if you only need detection. If your differences are cosmetic, plain responsive CSS remains the cheapest and most cache-friendly option.