Mobile Cm Php Laravel Package

Getting Started

This is a plain PHP library, not a Laravel package — there is no service provider, no facade, no config file to publish. Plan for a few minutes of manual wiring.

1. Install and inspect first. composer require malico/mobile-cm-php then open vendor/malico/mobile-cm-php/src/ and the README before writing any code. The package is small (single-purpose prefix lookup), so reading the whole source takes a minute and tells you the real class name, method signature, and return shape (string network name vs. enum vs. object). Treat the README as possibly stale and the source as the source of truth.
2. Pin to 1.3.x and confirm the constraint resolves. Release 1.3.1 explicitly declares PHP 7 and PHP 8 support — union type hints were removed so the code parses on PHP 7 — so the --ignore-platform-reqs workaround the earlier guidance suggested is far less likely to be needed. Still check composer.json for the actual php and illuminate/* constraints: "tested for php8 and php7" is a release-note claim, not a guarantee your 8.3/8.4 runtime is covered. Verify it installs cleanly on your interpreter before designing around it.
3. Smoke-test the entry point in tinker. Something along the lines of Mobile::getNetwork('6XXXXXXXX') (confirm the exact call from source) run against a handful of known MTN, Orange, Nexttel and Camtel numbers. Write down the return value for unknown/invalid input — null, false, an empty string, or an exception changes everything downstream.
4. First use case. The realistic day-one job is normalising Cameroonian numbers at registration or checkout and storing a network column, so you can route SMS/OTP traffic or segment customers. Wrap the call in your own small service class rather than scattering the vendor class through controllers — you want one seam to swap it out.

Implementation Patterns

Wrap it, don't call it directly. Bind a thin adapter in a service provider so the vendor class appears in exactly one file:

// app/Services/NetworkResolver.php
class NetworkResolver
{
    public function for(string $phone): ?string
    {
        return Mobile::getNetwork($this->normalize($phone)); // verify method name
    }
}

This is your insurance policy: the library is small and thinly maintained, and swapping to a hand-rolled prefix table later becomes a one-file change.

Normalise before lookup. Strip +237, leading 00237, spaces, dashes and parentheses first. The library almost certainly expects a bare local number (9 digits starting 6), and throwing +237 6XX XX XX XX at it will silently return "unknown" rather than erroring — the worst failure mode.

Model it as a stored attribute. Resolve once at write time, not on every read:

protected static function booted(): void
{
    static::saving(function ($user) {
        if ($user->isDirty('phone')) {
            $user->phone_network = app(NetworkResolver::class)->for($user->phone);
        }
    });
}

Backfill existing rows with a queued command and chunkById, since the lookup is per-row and cheap but you don't want it in a migration.

Validation rule. A Rule object that fails on null network is a clean way to reject invalid numbers at registration, and gives you one place to add an allowlist if you only support certain carriers:

Validator::extend('cm_mobile', fn ($attr, $value) => app(NetworkResolver::class)->for($value) !== null);

Cache the mapping. The result is a pure function of the prefix, so cache per-prefix (Cache::remember("cm_net:{$prefix}", 86400, ...)) if you resolve in bulk. Per-phone caching is wasteful — key on the first 2–3 digits.

Config-driven allowlist. Put your supported networks in config/telecom.php and let callers ask "is this a supported network?" instead of comparing magic strings throughout the codebase. This is also where you put your prefix table if you end up replacing the package.

Integration tips. Use it inside an onboarding/OTP job to pick the SMS gateway credential set per carrier. If you're doing CSV imports, resolve in a LazyCollection pipeline so a 50k-row file doesn't balloon memory, and log unmatched numbers to a side table for manual review rather than failing the import.

Gotchas and Tips

• Thinly maintained, near-zero adoption. 1.3.1 shows the author still touches the project, but a PHP-compatibility tidy-up is not evidence of ongoing prefix-table maintenance. No dependents means no one is filing the bugs you'll hit. Budget for reading and possibly vendoring the source. For a prefix table this small, a 40-line internal implementation is a legitimate alternative — decide based on whether you need portability (number porting breaks prefix lookup entirely, by the way).
• 1.3.1 is compatibility-only. The changelog is "tested for php8 and php7" plus removal of union type hints to permit PHP 7. No new features, no new prefixes, no API changes — so nothing in your integration needs rewriting if you were already on 1.x. The practical effect is that the package is now a lowest-common-denominator PHP 7 codebase: expect untyped signatures and hand-rolled validation inside, not modern union types or typed properties.
• Prefix tables go stale. Regulators reassign blocks and new operators launch. Any hardcoded prefix list in the vendor source is frozen at its release date, and 1.3.1 gives no sign of a table refresh. Keep your own authoritative table in config and use the package only as a first pass, or you'll get false "unknown" results on valid new ranges.
• Silent unknown vs. exception. Determine which one the library does. If it returns null for both "invalid format" and "unrecognised prefix", you can't distinguish user error from a stale table — log the raw input alongside the result so debugging is possible.
• No service provider means no auto-discovery. Don't assume Mobile:: resolves out of the box; either use the fully-qualified class or alias it. If the class is static-only with a private constructor, you cannot mock it in tests — hence the adapter.
• PHP 8 strictness, re-checked on 8.3+. Union types were deliberately removed for PHP 7 support, which means fewer type errors but also no compile-time enforcement of what you pass in. "Tested for php8" in a 1.3.1 note should not be read as tested against 8.3/8.4 — if you see deprecation notices on newer runtimes they're benign but noisy; suppress them at the boundary, not globally.
• Porting breaks lookup. A customer who keeps their number while switching from MTN to Orange will be misclassified forever. Treat the resolved network as a hint for routing, never as a billing or identity fact.
• Test with a fixture matrix. Keep a table of ~20 known numbers (each operator, plus +237 variants, plus garbage) in a data provider. This is your regression suite, and it's also exactly what you'd reuse if you rewrite the lookup yourself — run it once more after the 1.3.1 bump to confirm nothing shifted.
• Extension point is the source. There's no registry or config to extend — adding a prefix means editing vendor code, which composer install will erase. If you need new ranges, copy the table into your own config now rather than patching vendor/. Constrain to ^1.3 in composer.json so an untested 1.4 bump can't silently change the lookup.
• Debugging tip. When a lookup returns something surprising, dump the exact string you passed in (length, invisible characters, locale digits). Most "the package is broken" reports are a formatting problem on the caller side.